#rest
#rest
Вопрос:
Допустим, есть продукт с заказами. Если вы запросите /products/product_id, он вернет 404, если product_id не существует. Но должен ли /products/product_id/orders возвращать 404, если для этого продукта не существует заказов, или он должен возвращать пустой массив?
Комментарии:
1. вы можете определить свои собственные результаты. Дайте каждому результату различный идентификатор
2. 1: Мы обсуждаем тот же вопрос прямо сейчас, с подборками предложений видео.
3. @Grumpy не могли бы вы подробнее объяснить, что вы имеете в виду?
Ответ №1:
Я бы вернул пустую коллекцию. Продукт с нулевыми заказами является полностью допустимой концепцией, поэтому существование пустой коллекции orders имеет больше смысла, чем 404, из которого следовало бы, что у этого продукта нет коллекции orders.
Комментарии:
1. 1, Мы пошли этим путем, и я доволен решением.
2. Следует ли считать orders самостоятельным ресурсом? или часть информации, возвращаемой ресурсом product_id?
3. Ваше будущее «я» поблагодарит вас за это, когда вы решите, что хотите вернуть метаданные о самой коллекции (например, имена, описания (ваши сообщения описывают сами себя, верно?), версии, ссылки и т.д.), Независимо от того, есть ли какие-либо элементы в коллекции.
4. В дополнение к возврату пустой коллекции или вместо него вы также можете использовать код состояния 204 («Нет содержимого»), который немного похож на 404, но поскольку он находится в 200-х годах, нет никаких оснований полагать, что пользователь / клиент допустил ошибку (т. Е. неправильно ввел URL или что-то в этом роде).
5. @MatrixFrog Проблема с возвратом 204 заключается в том, что если пользователь выполняет поиск, и он возвращает некоторые значения, а затем они выполняют другой поиск, который не возвращает значений, агент пользователя не должен обновлять пользовательский интерфейс после 204. Поэтому пользователь будет думать, что он снова получил те же результаты.
Ответ №2:
Вы действительно должны сделать только одну из двух вещей
Либо возвращает 200 (OK) код состояния, либо пустой массив в теле.
Или возвращать 204 (NO CONTENT) код состояния и ОТСУТСТВИЕ тела ответа.
Мне вариант 2 кажется более технически правильным и соответствующим принципам REST и HTTP.
Однако вариант 1 кажется более эффективным для клиента — потому что клиенту не нужна дополнительная логика для различения двух кодов состояния (успех). Поскольку он знает, что всегда будет получать массив, он просто должен проверить, не получил ли он ни одного, одного или многих элементов, и обработать его соответствующим образом
Комментарии:
1. Спасибо. Это рассуждение имеет смысл для меня.
Ответ №3:
Не возвращать массивы. Возвращать объект в любом случае, например
{
offset: 30,
limit: 10,
arr: []
}
это позволяет вам добавлять метаданные (для разбивки на страницы или чего-то еще)
обычно с кодом состояния http: 200
Кроме того, это обычное поведение веб-API, обусловленное соображениями безопасности: https://cheatsheetseries.owasp.org/cheatsheets/AJAX_Security_Cheat_Sheet.html#always-return-json-with-an-object-on-the-outside
Комментарии:
1. Ссылка повреждена, поэтому этот ответ теперь в значительной степени является ответом только для ссылок
Ответ №4:
На мой взгляд:
Здесь мы говорим о значениях статуса http, и они должны быть более высокого уровня предоставления ответов.
Это следует видеть в слоях делегатов. Например, когда ваш api не может ответить на запрос, в случае, если сам вызов api недоступен, вы могли бы ответить 404.
Но когда ваш вызов существует, и он может ответить набором данных, но это пустая коллекция, вы можете вернуть просто http 200 с пустым результатом.
Я бы использовал значения состояния http, чтобы указать на проверку запроса, а не напрямую ставить его в зависимость от содержимого на более глубоких уровнях api.
Или можно строго следовать протоколам, найденным в сети, но никто им не следует…