Будет ли это рассматриваться как плохой дизайн RESTFul?

Я работаю над разработкой API впервые в Spring, и у меня есть следующий вариант использования:

  1. Получить все продукты.
  2. Получить продукты по ID.

Теперь, что я сделал, я сделал один API для этого,

@Path("/products")
public interface ProductResource {

    @GET
    @ApiOperation(value = "Gets all the products by criteria")
    Response getProductsByCriteria(@Context UriInfo uriInfo);
}

Что я делаю, я беру идентификатор в параметре запроса. Если его значение равно нулю, я вызову метод (на уровне сервиса) для возврата всех продуктов, в противном случае я вызову метод для возврата определенного продукта на основе его идентификатора (входящего в параметр запроса).

Я просто хочу знать, это плохой дизайн RESTFul? Должен ли я вместо этого иметь два отдельных API для получения продуктов на основе их идентификаторов и для получения всех продуктов?

3 ответа

Я бы предложил иметь отдельные конечные точки:

  • GET /products для всех продуктов
  • GET /products/{productId} для получения продукта по определенному идентификатору, который будет передан как PathParam, Таким образом, у вас могут быть другие конечные точки для манипулирования данными о продукте, например PUT /products/{productId} или же DELETE /products/{productId}, Они вернут HTTP-статус NOT FOUND (404) если товар не найден.

QueryParam более подходит для фильтрации продуктов по какой-либо характеристике, например GET /products?color=red,

Вы обязательно должны иметь

  • GET /products - возвращает список всех товаров
  • GET /products/:id - который возвращает один продукт или 404, если продукт не найден

Таким образом, его намного легче читать, и это согласуется с другими качественными API, которые вы можете найти в Интернете.

Смешивая getAll и getById, вы упускаете важный момент: вызывающий API не может узнать, существует ли productId. Обычно вы возвращаете 404 при получении для идентификатора продукта, который не существует.

Итак, чтобы ответить на ваш вопрос: да, это спокойная ошибка дизайна.

Другие вопросы по тегам