Предположим, что есть Продукт с заказами. Если вы попросите /products/product _id, он вернет 404, если product_id не существует. Но должны ли /products/product _id/orders возвращать 404, если для этого продукта не существует заказов или он должен возвращать пустой массив?
Должен ли RESTful API возвращать 404 для массивов объектов?
Ответ 1
Я бы возвратил пустую коллекцию. Продукт с нулевыми порядками является вполне действительным понятием, поэтому существование пустых коллекций заказов имеет больше смысла, чем 404, который предполагает, что этот продукт не имеет коллекции заказов.
Ответ 2
Не возвращайте массивы. Верните объект в любом случае, например
{
offset: 30,
limit: 10,
arr: []
}
он позволяет добавлять метаданные (для pagination или smth else)
обычно с кодом статуса http: 200
Кроме того, это обычное поведение веб-API, вызванное безопасностью: https://www.owasp.org/index.php/OWASP_AJAX_Security_Guidelines#Always_return_JSON_with_an_Object_on_the_outside
Ответ 3
Вам действительно нужно сделать только одну из двух вещей
Верните код состояния 200 (OK)
и пустой массив в теле.
Или Вернуть a 204 (NO CONTENT)
код статуса и тело ответа NO.
Для меня вариант 2 выглядит более технически корректным и поддерживается в соответствии с принципами REST и HTTP.
Однако вариант 1 кажется более эффективным для клиента - потому что клиенту не нужна дополнительная логика для различения двух (успешных) кодов состояния. Поскольку он знает, что он всегда будет получать массив, он просто должен проверить, не получил ли он ни одного, одного или нескольких элементов и соответствующим образом обработал его
Ответ 4
По-моему:
Мы говорим здесь о значениях статуса http и должны иметь более высокий уровень ответов.
Это нужно увидеть в слоях делегатов. Например, когда ваш api не может ответить на запрос, в случае, если сам вызов api недоступен, вы можете ответить с помощью 404.
Но когда ваш вызов существует и он может отвечать набором данных, но его пустой коллекцией, вы можете вернуть только http 200 с пустым результатом.
Я бы использовал значения статуса http, чтобы дать указание на проверку запроса, а не напрямую зависеть от содержимого в более глубоких слоях api.
Или можно строго следовать протоколам, найденным в сети, но никто не следует за ними...