Должен ли RESTful API возвращать 404 для массивов объектов?

Question

Допустим, есть продукт с заказами.Если вы запросите / products / product_id, он вернет 404, если product_id не существует.Но должен ли / products / product_id / orders возвращать 404, если для этого товара нет заказов, или он должен возвращать пустой массив?

Answer 1

Я бы вернул пустую коллекцию. Продукт с нулевыми заказами является полностью допустимой концепцией, поэтому наличие пустой коллекции заказов имеет больше смысла, чем 404, из чего следует, что у этого продукта нет коллекции заказов.

Answer 2

Не возвращать массивы.Возврат объекта в любом случае, например

{ 
   offset: 30,
   limit: 10,       
   arr: []
}

, он позволяет добавлять метаданные (для нумерация страниц или что-то еще)

обычно сhttp status code: 200

Кроме того, это обычное поведение веб-API, обусловленное проблемами security : https://www.owasp.org/index.php/OWASP_AJAX_Security_Guidelines#Always_return_JSON_with_an_Object_on_the_outside

Answer 3

Вы действительно должны сделать только одну из двух вещей

Либо вернуть код состояния 200 (OK) и пустой массив в теле.

, либо вернуть204 (NO CONTENT) код состояния и тело ответа НЕТ.

Мне кажется, вариант 2 технически более корректен и соответствует принципам REST и HTTP.

Однако вариант 1 кажется более эффективным дляклиент - потому что клиенту не нужна дополнительная логика для различения двух (успешных) кодов состояния.Поскольку он знает, что он всегда получит массив, ему просто нужно проверить, нет ли у него ни одного, одного или нескольких элементов, и обработать его соответствующим образом

Answer 4

На мой взгляд:

Мы говорим здесь о значениях статуса http, и должны иметь более высокий уровень предоставления ответов.

Это нужно видеть в слоях делегатов. Например, если ваш API не может ответить на запрос, если сам вызов API недоступен, вы можете ответить 404.

Но когда ваш вызов существует и он может ответить набором данных, но это пустой набор, вы можете вернуть только http 200 с пустым результатом.

Я бы использовал значения статуса http, чтобы указать индикацию проверки запроса, а не напрямую зависеть от содержимого в более глубоких слоях API.

Или можно строго следовать протоколам, найденным в сети, но никто не следует им ...