Какой правильный код ответа REST для действительного запроса, но пустых данных?

Например, вы выполняете запрос GET для, users/9но нет пользователя с идентификатором # 9. Какой код ответа лучше?

• 200 ОК
• 202 Принято
• 204 Нет содержимого
• ошибка 400, неверный запрос
• 404 Не Найдено

TL; DR: использовать 404

Смотрите этот блог . Это очень хорошо объясняет.

Сводка комментариев блога на 204:

1. 204 No Content не очень полезен в качестве кода ответа для браузера (хотя в соответствии со спецификацией HTTP браузеры должны понимать его как код ответа «не меняйте представление»).
2. 204 No Content это , однако, очень полезно для AJAX веб - сервисов , которые могут хотеть , чтобы указать успех без необходимости что- то вернуть. (Особенно в таких случаях, как DELETEили POSTс, которые не требуют обратной связи).

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

Другие коды ответов, которые даже менее подходят, чем 204и 404:

1. 200должны быть возвращены с телом того, что вы успешно получили. Не подходит, когда сущность, которую вы выбираете, не существует.
2. 202используется, когда сервер начал работу с объектом, но объект еще не полностью готов. Конечно, дело не в этом. Вы не начали и не начнете создание пользователя 9 в ответ на GETзапрос. Это нарушает все виды правил.
3. 400используется в ответ на плохо отформатированный HTTP-запрос (например, искаженные заголовки http, неправильно упорядоченные сегменты и т. д.). Это почти наверняка будет обработано любой платформой, которую вы используете. Вам не придется иметь дело с этим, если вы не пишете свой собственный сервер с нуля. Редактировать : более новые RFC теперь позволяют использовать 400 для семантически неверных запросов.

Википедия Описание кодов состояния HTTP в особенно полезно. Вы также можете увидеть определения в документе HTTP / 1.1 RFC2616 на www.w3.org

Я категорически против 404 в пользу 204 или 200 с пустыми данными. Или, по крайней мере, следует использовать объект ответа с 404.

Запрос был получен и правильно обработан - он вызвал код приложения на сервере, поэтому нельзя сказать, что это была ошибка клиента, и поэтому весь класс кодов ошибок клиента (4xx) не подходит.

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

Это может быть фатальным: представьте себе бухгалтерскую службу в вашей компании, в которой перечислены все сотрудники, которые должны получить ежегодный бонус. К сожалению, один раз, когда он вызывается, он возвращает 404. Означает ли это, что никто не должен получить бонус, или что приложение в настоящее время закрыто для нового развертывания?

-> Для приложений, которые заботятся о качестве своих данных, 404 без объекта ответа, таким образом, в значительной степени является запретом.

Кроме того, многие клиентские платформы отвечают на 404, выдавая исключение без дополнительных вопросов. Это вынуждает разработчика клиента перехватить это исключение, оценить его, а затем принять решение на основе этого: регистрировать ли его как ошибку, обнаруженную, например, компонентом мониторинга, или игнорировать ее. Это тоже не кажется мне симпатичным.

Преимущество 404 над 204 состоит в том, что он может возвращать объект ответа, который может содержать некоторую информацию о том, почему запрошенный ресурс не был найден. Но если это действительно актуально, то можно также рассмотреть возможность использования ответа «200 OK» и спроектировать систему таким образом, чтобы можно было реагировать на ошибки в данных полезной нагрузки. В качестве альтернативы можно использовать полезную нагрузку ответа 404 для возврата структурированной информации вызывающей стороне. Если он получает, например, html-страницу вместо XML или JSON, которую он может проанализировать, то это хороший индикатор того, что что-то техническое пошло не так, вместо ответа «нет результата», который может быть действительным с точки зрения вызывающего. Или для этого можно использовать заголовок ответа HTTP.

Тем не менее, я бы предпочел 204 или 200 с пустым ответом, хотя. Таким образом, статус технического выполнения запроса отделен от логического результата запроса. 2xx означает «техническое исполнение хорошо, это результат, разберитесь с ним».

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

Еще одна быстрая аналогия: возвращать 404 для «результат не найден» - это все равно, что выдавать исключение DatabaseConnectionException, если запрос SQL не дал результатов. Он может выполнить работу, но существует множество возможных технических причин, которые вызывают одно и то же исключение, которое затем будет ошибочно принято за действительный результат.

Сначала я думал, что 204 будет иметь смысл, но после обсуждений я считаю, что 404 - единственно верный правильный ответ. Рассмотрим следующие данные:

Пользователи: Джон, Питер

METHOD  URL                      STATUS  RESPONSE
GET     /users                   200     [John, Peter]
GET     /users/john              200     John
GET     /users/kyle              404     Not found
GET     /users?name=kyle`        200     []
DELETE  /users/john              204     No Content

Немного предыстории:

1. поиск возвращает массив, у него просто нет совпадений, но у него есть содержимое: пустой массив .

2. 404, конечно, лучше всего известен по URL-адресам, которые не поддерживаются запрашиваемым сервером, но отсутствующий ресурс фактически тот же.
   Несмотря на то, /users/:nameсопоставляется с users/kyle, пользователь Кайл не доступен ресурс поэтому 404 все еще применяется. Это не поисковый запрос, это прямая ссылка по динамическому URL , так что 404 это так.

Во всяком случае, мои два цента :)

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

Поэтому я бы предпочел, чтобы / items возвращали 200 OK с {"Items": []}, а не 204 вообще ни с чем, потому что таким образом коллекцию с 0 элементами можно обрабатывать так же, как коллекцию с одним или больше предмета в нем.

Я бы просто оставил 204 No Content для PUT и DELETE, где может быть так, что на самом деле нет полезного представления.

В случае, если / thing / 9 действительно не существует, 404 подходит.

В предыдущих проектах я использовал 404. Если нет пользователя 9, то объект не был найден. Поэтому 404 Not Found является подходящим.

Для объекта существует, но нет данных, 204 Нет содержимого будет подходящим. Я думаю, что в вашем случае объект не существует, хотя.

Согласно сообщению w3 ,

200 ОК

Запрос успешно выполнен. Информация, возвращаемая с ответом, зависит от метода, используемого в запросе

202 Принято

Запрос принят к обработке, но обработка не завершена.

204 Нет содержимого

Сервер выполнил запрос, но ему не нужно возвращать тело объекта, и он может захотеть вернуть обновленную метаинформацию.

ошибка 400, неверный запрос

Сервер не может понять запрос из-за неправильного синтаксиса. Клиент НЕ ДОЛЖЕН повторять запрос без изменений

401 Несанкционированный

Запрос требует аутентификации пользователя. Ответ ДОЛЖЕН включать поле заголовка WWW-Authenticate

404 Не Найдено

Сервер не нашел ничего, соответствующего Request-URI. Не указано, является ли состояние временным или постоянным

Подводя итог или упростить,

2xx: необязательные данные: правильно сформированный URI: критерии не являются частью URI: если критерий является необязательным, его можно указать в @RequestBody, а @RequestParam должен привести к 2xx. Пример: фильтр по имени / статусу

4xx: ожидаемые данные: неправильно сформированный URI: критерии являются частью URI: если критерии являются обязательными, которые могут быть указаны только в @PathVariable, то это должно привести к 4xx. Пример: поиск по уникальному идентификатору.

Таким образом, для заданной ситуации: «users / 9» будет 4xx (возможно, 404), но для «users? Name = superman» должно быть 2xx (возможно, 204)

Есть два вопроса. Один в заголовке и один в примере. Я думаю, что это отчасти привело к разногласиям относительно того, какой ответ уместен.

Заголовок вопроса спрашивает о пустых данных. Пустые данные - это данные, но они не совпадают с данными. Так что это предлагает запросить набор результатов, то есть список, возможно, из/users . Если список пуст, он все равно является списком, поэтому наиболее подходящим является 204 (без содержимого). Вы только что запросили список пользователей и получили его, так что у него просто нет контента.

Приведенный пример вместо этого спрашивает о конкретном объекте, о пользователе /users/9. Если пользователь № 9 не найден, пользовательский объект не возвращается. Вы запросили конкретный ресурс (объект пользователя) и не получили его, потому что он не был найден, поэтому 404 подходит.

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

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

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

Посмотрев вопрос, вы не должны использовать 404почему?

На основании RFC 7231 правильный код статуса204

В ответах выше я заметил одно небольшое недоразумение:

1.- ресурс это: /users

2.- /users/8это не ресурс, это: ресурс /usersс параметром маршрута8 , потребитель, возможно, не может заметить это и не знает разницу, но издатель знает и должен это знать! ... поэтому он должен вернуть точный ответ для потребителей. период.

так:

Основано на RFC: 404 неверно, потому что ресурсы /usersнайдены, но логика, выполненная с использованием параметра 8, не нашла ни одного, contentчтобы возвращать в качестве ответа, поэтому правильный ответ:204

Главное здесь: 404даже не был найден ресурс для обработки внутренней логики.

204является: Я нашел ресурс, логика была выполнена, но я не нашел никаких данных, используя ваши критерии, указанные в параметре маршрута, поэтому я не могу ничего вам вернуть. Извините, проверьте ваши критерии и позвоните мне снова.

200: хорошо, я нашел ресурс, логика была выполнена (даже когда я не вынужден ничего возвращать), возьмите его и используйте по своему желанию.

205: (лучший вариант ответа GET) Я нашел ресурс, логика была выполнена, у меня есть какой-то контент для вас, используйте его хорошо, кстати, если вы собираетесь поделиться этим в представлении, обновите представление до показать это.

Надеюсь, поможет.

Что существующие ответы не уточняют, так это то, что имеет значение, используете ли вы параметры пути или параметры запроса.

• В случае параметров пути этот параметр является частью пути ресурса. В случае /users/9, ответ должен быть, 404потому что этот ресурс не был найден. /users/9является ресурсом, и результат унарный, или ошибка, он не существует. Это не монада.
• В случае параметров запроса этот параметр не является частью пути к ресурсу. В случае /users?id=9, ответ должен быть, 204потому что ресурс /usersбыл найден, но он не мог возвратить никакие данные. Ресурс /usersсуществует, и результат n-арный, он существует, даже если он пуст. Если idуникален, это является монадой.

Использовать ли параметры пути или параметры запроса, зависит от варианта использования. Я предпочитаю параметры пути для обязательных, нормативных или идентифицирующих аргументов и параметры запроса для необязательных, ненормативных или атрибутивных аргументов (таких как разбиение на страницы, локаль сопоставления и прочее). В REST API я бы использовал /users/9не /users?id=9особенно из-за возможного вложения для получения «дочерних записей», таких как /users/9/ssh-keys/0получение первого открытого ключа ssh или /users/9/address/2получение третьего почтового адреса.

Я предпочитаю использовать 404. Вот почему:

• Вызовы унарных (1 результат) и n-арных (n результатов) методов не должны изменяться без уважительной причины. Мне нравится иметь одинаковые коды ответов, если это возможно. Число ожидаемых результатов, конечно, является разницей, скажем, вы ожидаете, что тело будет объектом (унарным) или массивом объектов (n-арных).
• Для n-a, я бы возвратил массив, и в случае отсутствия результатов я бы не возвратил никакого набора (без документа), я бы возвратил пустой набор (пустой документ, как пустой массив в JSON или пустой элемент в XML ). То есть это все еще 200, но с нулевыми записями. Нет причин размещать эту информацию на проводе, кроме как в теле.
• 204это как voidметод. Я бы не использовать его для GET, только POST, PUTи DELETE. Я делаю исключение в случае, GETкогда идентификаторы являются параметрами запроса, а не параметрами пути.
• Не найдя записи, как NoSuchElementException, ArrayIndexOutOfBoundsExceptionили что - то подобное, вызванное клиентом, идентификатор , который не существует, поэтому, это ошибка клиента.
• С точки зрения кода получение 204означает дополнительную ветвь в коде, которой можно избежать. Это усложняет клиентский код, а в некоторых случаях также усложняет серверный код (в зависимости от того, используете ли вы монады сущностей / моделей или простые сущности / модели), и я настоятельно рекомендую держаться подальше от монад сущностей / моделей, это может привести к неприятным ошибкам, поскольку из монады вы думаете, что операция прошла успешно, и возвращайте 200 или 204, когда вы действительно должны были вернуть что-то еще).
• Код клиента легче написать и понять, если 2xx означает, что сервер сделал то, что запросил клиент, а 4xx означает, что сервер не сделал то, что запросил клиент, и это ошибка клиента. Не предоставление клиенту записи о том, что клиент, запрошенный по идентификатору, является ошибкой клиента, потому что клиент запросил идентификатор, который не существует.

Последнее, но не менее важное: последовательность

• GET /users/9
• PUT /users/9 и DELETE /users/9

PUT /users/9и DELETE /users/9уже должны вернуться 204в случае успешного обновления или удаления. Так что они должны вернуть, если пользователь 9 не существует? Нет смысла представлять ту же ситуацию в виде разных кодов состояния в зависимости от используемого метода HTTP.

Кроме того, не нормативная, а культурная причина: если в проекте 204используется GET /users/9следующая вещь, это то, что кто-то думает, что возвращение 204хорошо для n-арных методов. И это усложняет клиентский код, потому что вместо того, чтобы просто проверять 2xxи затем декодировать тело, клиент теперь должен специально проверять 204и в этом случае пропускать декодирование тела. Буд, что клиент делает вместо этого? Создать пустой массив? Почему бы тогда не иметь это на проводе? Если клиент создает пустой массив, 204 является формой глупого сжатия. Если клиент использует nullвместо этого, открывается совершенно другая банка червей.

Twitter использует 404 с пользовательским сообщением об ошибке типа «Данные не найдены».

Ссылка: https://developer.twitter.com/en/docs/basics/response-codes.html

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

Я бы сказал, ни то, ни другое не подходит. Как уже было сказано - например, @anneb, я тоже думаю, что часть проблем возникает из-за использования кода ответа HTTP для передачи статуса, относящегося к RESTful-сервису. Все, что служба REST может сказать о своей собственной обработке, должно передаваться с помощью специальных кодов REST.

1

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

Давайте на минуту предположим следующий URL: http://example.com/service/return/test.

• Случай А заключается в том, что сервер «просто ищет файл в файловой системе». Если этого нет, 404правильно. То же самое верно, если он запрашивает какой-либо сервис для доставки именно этого файла, и этот сервис сообщает, что ничего с таким именем не существует.
• В случае B сервер не работает с «настоящими» файлами, но на самом деле запрос обрабатывается какой-то другой службой, например какой-то системой шаблонов. Здесь сервер не может предъявлять никаких претензий о существовании ресурса, поскольку он ничего не знает о нем (если только об этом не сообщит служба, обрабатывающая его).

Без какого-либо ответа от сервиса, явно требующего другого поведения, HTTP-сервер может сказать только 3 вещи:

• 503 если служба, которая должна обрабатывать запрос, не работает или не отвечает;
• 200 в противном случае HTTP-сервер может фактически удовлетворить запрос - независимо от того, что служба скажет позже;
• 400или 404указать, что такой службы нет (в отличие от «существует, но в автономном режиме») и ничего больше не найдено.

2

Возвращаясь к рассматриваемому вопросу: я думаю, что самым чистым подходом было бы не использовать HTTP-код ответа вообще, кроме указанного ранее. Если служба присутствует и отвечает, код HTTP должен быть 200. Ответ должен содержать статус, возвращенный службой в отдельном заголовке - здесь служба может сказать

• REST:EMPTYнапример, если его попросили найти что-нибудь. и это исследование вернулось пустым;
• REST:NOT FOUNDесли бы его спросили специально для чего-то. «ID-like» - будь то имя файла или ресурс по идентификатору или записи № 24 и т. Д. - и этот конкретный ресурс не был найден (обычно один конкретный ресурс был запрошен и не найден);
• REST:INVALID если какая-либо часть запроса была отправлена, сервис не распознается.

(обратите внимание, что я поставил перед ними префикс «REST:», чтобы отметить тот факт, что, хотя они могут иметь те же значения или формулировку, что и коды ответов HTTP, они полностью отличаются)

3

Давайте вернемся к приведенному выше URL и рассмотрим случай B, где служба указывает HTTP-серверу, что он не обрабатывает этот запрос сам, а передает его SERVICE. HTTP выдает только то, что ему передают SERVICE, он ничего не знает о той return/testчасти, которую он обрабатывает SERVICE. Если эта служба работает, HTTP должен вернуться, 200поскольку он действительно нашел что-то для обработки запроса.

Статус, возвращаемый SERVICE(и который, как сказано выше, хотел бы видеть в отдельном заголовке), зависит от того, какое действие фактически ожидается:

• если return/testзапрашивает конкретный ресурс: если он существует, вернуть его со статусом REST:FOUND; если этот ресурс не существует, вернуть REST:NOT FOUND; это можно продлить до возвращения, REST:GONEесли мы знаем, что когда-то оно существовало и не вернулось, и REST:MOVEDесли мы знаем, что оно перешло в Голливуд
• if return/testсчитается поисковой или фильтр-подобной операцией: если набор результатов пуст, вернуть пустой набор в запрошенном типе и статус REST:EMPTY; набор результатов в запрашиваемом типе и статусREST:SUCCESS
• if return/testне является операцией, распознанной с помощью SERVICE: return, REST:ERRORесли она полностью неверна (например, опечатка retrun/test), или REST:NOT IMPLEMENTEDесли она запланирована на потом.

4

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

• Если возвращается HTTP 404, сервер говорит мне: «Я понятия не имею, о чем ты говоришь». Хотя REST-часть моего запроса может быть совершенно нормальной, я ищу par'Mach во всех неправильных местах.
• С другой стороны, HTTP 200 и REST: ERR говорят мне, что я получил услугу, но сделал что-то не так в своем запросе к службе.
• Из HTTP 200 и REST: EMPTY, я знаю, что я не сделал ничего плохого - правильный сервер, сервер нашел службу, правильный запрос к службе - но результат поиска пуст.

Резюме

Проблема и обсуждение возникают из-за того, что коды ответов HTTP используются для обозначения состояния службы, результаты которой обслуживаются HTTP, или для обозначения sth. это не входит в сферу действия самого HTTP-сервера. Из-за этого несоответствия на вопрос невозможно ответить, и все мнения подлежат большому обсуждению.

Состояние запроса, обработанного службой, а не сервером HTTP, ДЕЙСТВИТЕЛЬНО НЕ ДОЛЖНО (RFC 6919) быть задано кодом ответа HTTP. Код HTTP СЛЕДУЕТ (RFC 2119) содержать только информацию, которую сервер HTTP может предоставить из своей собственной области: а именно, была ли найдена служба для обработки запроса или нет.

Вместо этого СЛЕДУЕТ использовать другой способ сообщить потребителю о состоянии запроса службе, которая фактически обрабатывает запрос. Мое предложение сделать это через специальный заголовок. В идеале и название заголовка, и его содержание соответствуют стандарту, который облегчает потребителям работу с этими ответами.

Согласно RFC7231 - стр. 59 ( https://tools.ietf.org/html/rfc7231#page-59 ) определение ответа кода состояния 404:

6.5.4. 404 Not Found Код состояния 404 (Not Found) указывает, что исходный сервер не нашел текущее представление для целевого ресурса или не хочет раскрыть, что он существует. Код состояния 404 не указывает, является ли это отсутствие представления временным или постоянным; код состояния 410 (пропал) предпочтительнее, чем код 404, если исходный сервер знает, предположительно, через некоторые настраиваемые средства, что условие может быть постоянным. Ответ 404 кэшируется по умолчанию; т. е. если иное не указано в определении метода или явных элементах управления кэшем (см. раздел 4.2.2 [RFC7234]).

И главное, что вызывает сомнения - это определение ресурса в контексте выше. Согласно тому же RFC (7231) определение ресурса:

Ресурсы: цель HTTP-запроса называется «ресурсом». HTTP не ограничивает природу ресурса; он просто определяет интерфейс, который может использоваться для взаимодействия с ресурсами. Каждый ресурс идентифицируется унифицированным идентификатором ресурса (URI), как описано в разделе 2.7 [RFC7230]. Когда клиент создает сообщение запроса HTTP / 1.1, он отправляет целевой URI в одной из различных форм, как определено в (Раздел 5.3 [RFC7230]). Когда запрос получен, сервер восстанавливает эффективный URI запроса для целевого ресурса (раздел 5.5 [RFC7230]). Одна из целей разработки HTTP состоит в том, чтобы отделить идентификацию ресурса от семантики запроса, что стало возможным благодаря передаче семантики запроса в методе запроса (раздел 4) и нескольких полей заголовка, изменяющих запрос (раздел 5).

Таким образом, в моем понимании код состояния 404 не должен использоваться при успешном GET-запросе с пустым результатом. (Пример: список без результата для определенного фильтра)

Такие вещи могут быть субъективными, и с обеих сторон есть несколько интересных и разных весомых аргументов. Однако [по моему мнению] возвращать 404 за отсутствующие данные не правильно . Вот упрощенное описание, чтобы прояснить это:

• Запрос: Могу ли я получить некоторые данные, пожалуйста?
• Ресурс (конечная точка API): я получу этот запрос для вас, здесь [отправляет ответ потенциальных данных]

Ничего не сломалось, конечная точка была найдена, а таблица и столбцы были найдены, поэтому БД запросила и данные были «успешно» возвращены!

Теперь - независимо от того, есть ли у этого «успешного ответа» данные или нет, не имеет значения, вы запросили ответ «потенциальных» данных, и этот ответ с «потенциальными» данными был выполнен. Пустые, пустые и т. Д. Являются действительными данными.

200 означает, что любой запрос, который мы сделали, был успешным. Я запрашиваю данные, ничто не пошло не так с HTTP / REST, и когда данные (хотя и пустые) были возвращены, мой «запрос данных» был успешным.

Верните 200 и позвольте запрашивающей стороне иметь дело с пустыми данными, поскольку каждый конкретный сценарий гарантирует это!

Рассмотрим этот пример:

• Запрос: запрос "нарушения" таблицы с идентификатором пользователя 1234
• Ресурс (конечная точка API): возвращает ответ, но данные пусты

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

У вас нет нарушений, есть черничный кекс!

Если вы считаете это 404, что вы заявляете? Нарушения пользователя не могут быть найдены? Теперь, грамматически это правильно, но это просто неправильно в мире REST, где успех или неудача связаны с запросом. Данные о "нарушении" для этого пользователя могут быть успешно найдены, нарушений нет - действительное число, представляющее действительное состояние.

[Дерзкая записка ..]

В своем названии вы подсознательно соглашаетесь с тем, что 200 является правильным ответом:

Какой правильный код ответа REST для действительного запроса, но пустых данных?

Вот некоторые вещи, которые следует учитывать при выборе кода состояния, независимо от субъективности и хитрости выбора:

1. Согласованность . Если вы используете 404 для «нет данных», используйте его каждый раз, когда ответ не возвращает никаких данных.
2. Не используйте один и тот же статус для более чем одного значения . Если вы вернете 404, когда ресурс не найден (например, конечная точка API не существует и т. Д.), То не также используйте его, если данные не возвращаются. Это только делает борьбу с ответами болью.
3. Тщательно продумайте контекст . Что такое «запрос»? Что вы говорите, что пытаетесь достичь?

Кодируйте содержимое ответа с помощью общего перечисления, которое позволяет клиенту включать его и соответственно разветвлять логику. Я не уверен, как ваш клиент будет различать разницу между «данные не найдены» 404 и «веб-ресурс не найден» 404? Вы не хотите, чтобы кто-то просматривал пользователя Z / 9 и заставлял клиента удивляться, как если бы запрос был действительным, но данные не были возвращены.

Почему бы не использовать 410? Он предполагает, что запрошенный ресурс больше не существует, и ожидается, что клиент никогда не сделает запрос на этот ресурс, в вашем случае users/9.

Вы можете найти более подробную информацию о 410 здесь: https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

Грустно, что что-то такое простое и четкое стало «основанным на мнении» в этой теме.

HTTP-сервер знает только о «сущностях», которые являются абстракцией для любого контента, будь то статическая веб-страница, список результатов поиска, список других сущностей, описание чего-либо в формате json, файл мультимедиа и т. Д. И т. Д. И т. Д.

Предполагается, что каждый такой объект может быть идентифицирован по уникальному URL, например

• / пользователь / 9 - один объект: идентификатор пользователя = 9
• / users - один объект: СПИСОК всех пользователей
• /media/x.mp3 - один объект: медиа-файл с именем x.mp3
• / search - единая сущность: динамический CONTENT, основанный на параметрах запроса

Если сервер находит ресурс по заданному URL-адресу, не имеет значения, каково его содержимое - 2G данных, ноль, {}, [] - до тех пор, пока он существует, он будет равен 200. Но если такой объект является серверу неизвестно, ожидается 404 "Not Found".

Одна путаница, кажется, от разработчиков, которые думают, что если приложение имеет обработчик для определенной формы пути, это не должно быть ошибкой. В глазах протокола HTTP не имеет значения, что произошло во внутренних элементах сервера (т. Е. Ответил ли маршрутизатор по умолчанию или обработчик для определенной формы пути), если на сервере нет соответствующей сущности для запрошенный URL (который запрашивал файл MP3, веб-страницу, пользовательский объект и т. д.), который возвращал бы допустимое содержимое (пустое или иное), он должен быть 404 (или 410 и т. д.).

Другая путаница, кажется, связана с «нет данных» и «нет сущности». Первое касается содержания сущности, а второе - ее существования.

Пример 1:

• Нет данных: / users возвращает 200 OK, body: [], потому что никто еще не зарегистрирован
• Нет объекта: / users возвращает 404, потому что нет пути / users

Пример 2:

• Нет данных: / user / 9 возвращает return 200 OK, body: {}, потому что ID пользователя = 9 никогда не вводил свои личные данные
• Нет объекта: / user / 9 возвращает 404, потому что нет идентификатора пользователя = 9

Пример 3:

• Нет данных: / search? Name = Джо возвращает 200 OK [], потому что в БД нет Джо
• Нет объекта: / search? Name = Джо возвращает 404, потому что нет пути / поиска

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

Для меня достаточно кода ответа 200 с пустым телом, чтобы понять, что все идеально, но нет данных, соответствующих требованиям.

Согласно Microsoft: Типы возвращаемых действий контроллера в веб-API ASP.NET Core , прокрутив вниз почти до конца, вы обнаружите следующую ошибку около 404, касающуюся объекта, не найденного в базе данных. Здесь они предполагают, что 404 подходит для пустых данных.

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

Ожидается, что статус 200 будет содержать данные о ресурсах, так что это неправильный выбор. Состояние 204 означает что-то еще целиком и не должно использоваться в качестве ответа на запросы GET.

Все остальные существующие статусы не применимы по той или иной причине.

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

Это будет статус 2xx, потому что не обнаружение идентификатора не должно считаться ошибкой клиента (если клиенты знают все, что находится в БД сервера, им не нужно ничего запрашивать на сервере, не так ли?). Этот специальный статус решит все проблемы, обсуждаемые с использованием других статусов.

Единственный вопрос: как мне заставить RFC принять это как стандарт?