Правильный код состояния HTTP для существующего ресурса, но несуществующий объект?

Say клиент запрашивает следующий URL:Правильный код состояния HTTP для существующего ресурса, но несуществующий объект?

/user-details?user=123

Если /user-details был несуществующий ресурс, правильный код состояния, очевидно, будет 404.

Однако если /user-details существует, но ни один пользователь с идентификатором 123 не существует:

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

Есть ли более подходящий код статуса HTTP для этой цели?

источник

2014-01-04 Benjamin

Есть ли причина, по которой вам не удобно принимать один из текущих ответов? Что вы в конечном итоге использовали? – ruffin

Прочитав ответы ниже, я * думаю *, что '404' лучше, я просто не готов принять его еще, я полагаю;) – Benjamin

Попробуйте 422, который используется в WebDav? См. http://en.wikipedia.org/wiki/List_of_HTTP_status_codes

Для меня статус 404 тоже нормально (лучше нормировано на самом деле), 400 слишком расплывчато.

источник

2014-01-04 15:09:13 cubitouch

Интересный аргумент в пользу этого ответа [здесь] (https: // www .bennadel.com/блог/2434-HTTP-статус-кода-для-недействителен-данные-400-VS-422.htm): «* В частности, многие API-интерфейсы, такие как Twitter и Recurly, используют код состояния« 422 Unprocessable Entity », как определено в HTTP-расширении для WebDAV. *« – ruffin

Параметр user является частью идентификатора ресурса, как указано в RFC 3986, section 3.4:

Компонент запроса содержит не-иерархические данные, которые, наряду с данных в компоненте пути (раздел 3.3), служит для идентификации ресурсов в рамках схемы URI, и называя власть

Следовательно, 404/Not found это прекрасно.

источник

2014-01-04 17:58:38 DaSourcerer

Так что тот факт, что это часть строки запроса, а не путь не имеет значения? У вас есть какая-либо ссылка на некоторые ресурсы, поддерживающие это? – Benjamin

Я обновил свой ответ, чтобы содержать цитату из соответствующего RFC. – DaSourcerer

С точки зрения RESTful (если это был REST API) строки запроса используются для уточнения результата операции, что согласуется с использованием вопросительного знака. Он должен использоваться для служб, которые путь URI сопоставляется с набором объектов, а не с одним, например./Пользователей? Имя = Джон. Обычно вы увидите URI в качестве пути, идентифицирующего ресурс, например/users/123, который является синонимом/user/123. Имейте в виду, что несколько фреймворков используют этот подход для сопоставления запросов, поэтому использование строки запроса для идентификации ресурсов будет проблематично в этом смысле. – raspacorp

-3

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

источник

2014-01-04 21:01:02 Wins

Er ... как насчет возврата 404 и отображения удобного для пользователя сообщения? Сказав это, я ** не ** считаю, что код состояния, подразумевающий успешную операцию, здесь достаточно. – DaSourcerer

@DaSourcerer возможен, но, насколько я помню, браузер просто отобразит страницу 404 по умолчанию. Если вы не используете XHR, вы можете перехватить статус и прочитать тело HTTP, чтобы получить правильное сообщение об ошибке с сервера – Wins

, которое имеет место только с MSIE и страницами ошибок, которые короче определенного порога (512 байт, IIRC) , Во всех остальных случаях клиент будет отображать содержимое страницы ошибки, отправленной сервером. – DaSourcerer

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

Метод GET для пользовательских деталей не несет ответственности за отличие от двух случаев: a) Пользователь не существует, b) Сведения о пользователе не существуют.

Я бы, однако, переписать конечную точку на что-то вроде этого:

/user/123/details

на мой взгляд, является более выразительным.

источник

2015-05-20 18:53:36 raspacorp

Правильный код состояния HTTP для существующего ресурса, но несуществующий объект?

ответ

Смежные вопросы