Подходит ли http-код 404, если успешный запрос REST дает 0 результатов?

Question

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

Вот сценарий: у нас есть конечная точка API REST со статическим URI типа "https://server.domain.com/restapi/getnode", которая принимает тело json во время операции POST, чтобы проверить, существует ли сервер в базе данных. Существует 1сервер разрешен для каждого запроса.
В соответствии с тем, как он спроектирован, если сервер существует, он возвращает http-код 200, в котором тело сообщения является информацией о сервере в базе данных. Если оно не существует, они возвращаются.код 404 с сообщением «сервер x не найден в базе данных y».

Мне кажется, что это неверно, поскольку в соответствии со стандартами W3C 4xx коды предназначены для проблем, связанных с клиентоми 404, в частности, если сервер не может создать сервер для этого конкретного URI. Кроме того, это не является ошибкой, мы ожидаем не толькоиногда отрицательный / пустой ответ является частью обычного бизнеса, но ожидается, что это будет состояние большинства вызовов.

Их ответ на это таков, что согласно источникам, таким как Стандарты AWS REST и Стандарты REST ServiceNow , что 404 подходит, потому что запрос не нашел сервер, следовательно, он не смог найти ресурс (На мой взгляд, они неверно истолковывают термин «ресурс»).

Итак, кто здесь прав?Или это скорее серая зона, чем я думаю?

Answer 1

Соответствующей частью спецификации здесь является Ошибка клиента 4xx .

За исключением случаев, когда при ответе на запрос HEAD сервер ДОЛЖЕН отправить представление, содержащее объяснение ошибки.ситуация, и является ли это временным или постоянным условием.

ПАгентам СЛЕДУЕТ отображать любое включенное представление пользователю.

Другими словами, код состояния - это метаданные, которые указываютдля компонентов общего назначения, что полезная нагрузка ответа является объяснением ошибки, а не представлением ресурса.

Если то, что вы на самом деле делаете, возвращает представление ресурса, который находится в данный моментпустой список, значит, вы должны использовать код Successful, а не код ошибки клиента.

Например, если у нас есть ресурс, в котором перечислены женщины, приведенные к присяге в кабинете президента Соединенных Штатов,выражение этого ресурса по состоянию на 2019-09-25 будет пустым списком.Таким образом, стандартный HTTP-ответ будет выглядеть так:

200 OK
Content-Type: application/json

[]

С другой стороны, этот ответ говорит о совершенно другом

404 Not Found
Content-Type: application/json

[]

То, что это говорит о том, что не было текущего представления запрошенногоресурс, и представление объяснения проблемы является пустым списком, поэтому, пожалуйста, покажите пользователю пустой список, чтобы он знал, что делать.

Answer 2

Это бесконечная дискуссия без полезного исхода.См., Например, Как спроектировать поиск / фильтрацию RESTful? , Используют ли веб-приложения HTTP в качестве транспортного уровня или они считаются неотъемлемой частью HTTP-сервера? (заявление об отказе:мой вопрос), а также тысячи других вопросов в сети Stack Exchange и тысячи блогов, например "какой код состояния выбрать для сценария REST XYZ".

Тот факт, что вы используете POST для запроса с помощью GETсемантика означает, что вы уже неправильно применяете REST.POST используется для создания ресурсов, а не для поиска существующих ресурсов.Если у вас есть коллекция ресурсов «серверы», то вы имеете дело с ресурсами «сервера».

Если вы хотите иметь конечную точку «find-server» и хотите использовать POST для «создания»«результат поиска ресурса сервера», который вы можете затем выполнить GET-запросом для получения результатов поиска, вы мазохист, который пытается внедрить приложение в философию дизайна, которая не соответствует проблемной области.

Так что будьте прагматичны.Существует ли конечная точка?Да, так 404 не применяется.Вернуть 200 (ресурс существует, запрос правильный) с телом, указывающим, что результаты не найдены, или 204 («без содержимого») без тела.