Допустим, есть продукт с заказами. Если вы попросите/products/product_id, он вернет 404, если product_id не существует. Но должны ли/products/product_id/orders возвращать 404, если для этого продукта не существует заказов или он должен возвращать пустой массив?Должен ли RESTful API возвращать 404 для массивов объектов?
Я бы вернул пустую коллекцию. Продукт с нулевыми порядками является вполне действительным понятием, поэтому существование пустых коллекций заказов имеет больше смысла, чем 404, который предполагает, что этот продукт не имеет коллекции заказов.
+ 1, Мы пошли таким образом, и я чувствую себя счастливым с решением. – ale
Должны ли заказы считаться ресурсом в отдельности? или часть информации, возвращаемой ресурсом product_id? – chernevik
Черневик Да. Если это другой URL-адрес, и он может вернуть 200, то это другой ресурс. Сервер может обрабатывать оба ресурса с использованием одного и того же контроллера, но они представляют собой два разных ресурса. –
Вы действительно должны сделать только один двух вещей
Либо Возвращает 200 (OK) код состояния, и пустой массив в теле.
Или вернуть 204 (NO CONTENT) код статуса и тело ОТКЛОНЕНИЯ.
Для меня вариант 2 выглядит более технически корректным и соответствует принципам REST и HTTP.
Однако вариант 1 кажется более эффективным для клиента - поскольку клиенту не требуется дополнительная логика для различения двух (успешных) кодов состояния. Так как он знает, что он всегда будет получать массив, он просто должен проверить не получил ли он ни одного, один или много предметов и обработать его соответствующим образом
На моем взгляде:
Мы говорим значение состояния HTTP здесь, и должен быть более высокого уровня ответов.
Следует видеть это в слоях делегатов. Например, когда ваш api не может ответить на запрос, в случае, если сам вызов api недоступен, вы можете ответить с помощью 404.
Но когда ваш звонок существует и он может ответить коллекцией данных, но его пустую коллекцию, вы можете вернуть только http 200 с пустым результатом.
Я бы использовал значения статуса http, чтобы дать указание на проверку запроса, а не напрямую зависеть от содержимого в более глубоких слоях api.
Или можно было бы строго следовать протоколы, найденные в сети, но никто не следит за ними ...
Не возвращают массивы. Возвращает объект в любом случае, как
{
offset: 30,
limit: 10,
arr: []
}
это позволяет добавлять метаданные (для пагинацией или чего-л еще)
обычно с кодом состояния HTTP: 200
Кроме того, это это обычное поведение веб-API, приводимое в действие безопасность вопросы: https://www.owasp.org/index.php/OWASP_AJAX_Security_Guidelines#Always_return_JSON_with_an_Object_on_the_outside
лет u может определить ваши собственные результаты. Дайте каждому результату разный id – Grumpy
+1: Мы обсуждаем тот же вопрос прямо сейчас, с коллекциями видео предложений. –
@ Грумпи вы можете объяснить, что вы имеете в виду еще немного? – rbp