Какой код Http я должен вернуть для "Вещи не найдены"?

Question

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

Допустим, ради аргумента, что поисковый веб-хит:

GET /patrons/619 HTTP/1.1

Если меценат найден, я возвращаю код 200:

HTTP/1.1 200 OK

Если вы опустите или дадите номер счета, который не является номером, я верну 400. Например, следующие неправильные запросы:

GET /patrons HTTP/1.1
GET /patrons/ HTTP/1.1
GET /patrons/G619 HTTP/1.1
GET /patrons/kirsten%20guyer HTTP/1.1

вся ошибка возврата 400 (неверный запрос), например ::

HTTP/1.1 400 Invalid patron number

---

Я хочу получить код состояния для Патрон не найден , возвращенный в качестве кода состояния HTTP. Например:

GET /patrons/1322 HTTP/1.1

HTTP/1.1 404 Not Found

я думал об использовании 404 (не найдено) , что является действительным ответом (запрошенный ресурс действительно и правда не найден). Но я боятся, что отладчики могут подумать, что это означает, что они написали /patrons/ неправильно.

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

---

Обновление: Я смотрю в глаза

204 No Content 
The server successfully processed the request, but is not returning any content. 

Что скажете вы?

---

Не забывайте, что не все HTTP-серверы обслуживают HTML-контент. Если на веб-сервере IIS запрашивается ресурс под названием:

GET /MyStartPage.html HTTP/1.1

Тогда HTTP-сервер должен решить, что ответить. На большинстве веб-серверов ресурс / MyStartPage.html соответствует файлу, расположенному на жестком диске.

Принимая во внимание, что StackOverflow делает:

GET /posts/1027301 HTTP/1.1

Который, если этот ресурс не существует, веб-сервер должен (правильно) вернуть 404.

Answer 1

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

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

Возврат 500, когда приложение делает именно то, для чего оно предназначено, также кажется немного странным. 404 точно описывает ситуацию: ресурс не найден.

Answer 2

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

Answer 3

Ошибка 404 на самом деле является более приемлемым ответом для этого случая, потому что ресурс действительно не найден. У вас всегда может быть пользовательский документ с сообщением об ошибке, в котором объясняется, что это не идентификатор Patron ID.

Ошибка 400 означает, что клиент отправил искаженный синтаксис, что не так в вашем примере. Таким образом, вы не должны использовать этот код ошибки. Может показаться, что «Bad Request» является точным, но на самом деле это означает, что в синтаксисе заголовка запроса есть ошибка.

Это также не ошибка 500, потому что ошибки не произошло. Нет проблем с веб-сервером, выполняющим запрос, дело в том, что запрос ищет ресурс, которого нет.

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

Из моего исходного комментария на вопрос:

Не думаю, что ошибка 200-го уровня тоже будет уместна, рассмотрите объяснения на W3 w3.org / Protocols / rfc2616 / rfc2616-sec10.html

Answer 4

ИМХО, HTTP-ответ , а не - правильное место для обработки, поскольку ошибка не на уровне HTTP. Это на уровне приложения. Одним из возможных решений является использование шаблона нулевого объекта для возврата нулевого «патрона», который соответствует интерфейсу «патрона», но указывает, что такого человека не существует.

---

ОБНОВЛЕНИЕ: Я был убежден, что этот ответ неверен. Тем не менее, я хочу оставить это, поскольку это потенциально верный ответ (в зависимости от деталей, не представленных в вопросе), и я думаю, что комментарии поучительны.

Answer 5

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

Кроме того, еще одна причина, по которой я говорю «500», заключается в том, что, исходя из моего опыта работы с веб-службами .NET, всякий раз, когда я выбрасываю исключение по сети (например, исключение RecordNotFound), веб-сервер и клиент всегда интерпретируют ответом будет код состояния 500.

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

Answer 6

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

Answer 7

Это зависит от того, какой веб-сервис вы создаете.

Веб-службы SOAP и XML обычно возвращают 200 OK, если запрошенный объект (покровитель) не может быть найден, и кодируют тип ошибки / сообщение / описание в документе ответа. Они отделяют транспортный уровень (HTTP) от сообщений, которыми обмениваются (XML). Ошибка 404 (которая находится на транспортном уровне) возвращается только при запросе несуществующей конечной точки API (неправильный URL).

Однако, используя веб-сервис REST, вы используете методы и статусы HTTP непосредственно для обмена сообщениями. REST использует различные методы HTTP (GET / POST / PUT / DELETE), чтобы указать, какое действие требуется, и сервер возвращает статус в качестве статуса HTTP. Таким образом, в случае веб-службы REST, 404 будет правильным HTTP-статусом, если патрона не будет найдено.

500 в любом случае неуместен, так как 5xx означает, что на стороне сервера что-то не так (а это не так), а ошибки 4xx означают, что на стороне клиента что-то не так.

Answer 8

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

Однако я думаю, что более естественно, чтобы ответ веб-службы был полностью определен в теле HTTP-ответа, и просто возвращал 200 для успешного взаимодействия («Я понял ваш запрос и отправил вам соответствующий ответ») , Тогда в этом случае вы вернете 200 как обычно с полезной нагрузкой вашего запроса (XML или JSON или любым другим), указывающей, что не найдено ни одного соответствующего объекта

Я бы посчитал коды ошибок не-200 похожими на исключения в обычных языках программирования, а тело ответа HTTP больше похоже на код возврата. Представьте, если бы вы реализовывали это условно - вы бы выдавали исключение, если сущность не была найдена, или возвращали null? Лично, учитывая хрупкую природу сетевых подключений, я бы хотел зарезервировать все коды ошибок уровня HTTP для проблем со связью, и я бы скорее всегда всегда возвращал 200 OK из самой службы вместе с полезной нагрузкой, указывающей результат или любая ошибка уровня обслуживания.

Answer 9

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