REST: сопоставление ошибок приложения с HTTP-кодами состояния

Следует ли считать хорошей практикой повторное использование кодов состояния RFC HTTP следующим образом: или мы должны составлять новые, которые точно отображают > к нашим конкретным причинам ошибки?

Мы разрабатываем API веб-сервисов вокруг нескольких устаревших приложений.

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

Но как вы собираетесь сопоставлять различные классы ошибок с соответствующими кодами состояния HTTP? Все участники команды соглашаются на следующее:

GET/package/1234 возвращает 404 не найден, если 1234 не существует

GET/package/1234/next_checkpoint возвращает 400 Bad Request, если "next_checkpoint" и 1234 действительны для запроса, но next_checkpont здесь не имеет смысла...

и т.д.... но в некоторых случаях вещи должны быть более конкретными, чем просто "400" - например:

POST/dispatch/? for_package = 1234 возвращает 412 Precondition Failed, если/отправка и пакет 1234 существуют, но 1234 еще не готов к отправке.

(Изменить: Коды состояния в HTTP/1.1 и Коды состояния в WebDAV ext.)

Ответ 1

Использование RESTful HTTP означает, что вы должны поддерживать единообразный API. Это означает, что вы не можете добавлять методы, специфичные для домена (ala GET_STOCK_QUOTE), но это также означает, что вы не можете добавлять коды ошибок домена (ala 499 Product Out Of Stock).

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

Jan

Ответ 2

422 Unprocessable Entity - полезный код ошибки для таких сценариев. См. Этот вопрос какой http-код ответа для службы отдыха на методе put, когда правила домена недействительны для получения дополнительной информации.

Ответ 3

GET/package/1234/next_checkpoint возвращает 400 Bad Request, если "next_checkpoint" и 1234 действительны спросить, но next_checkpont здесь не имеет смысла...

Это неправильный способ подумать об этом URI.

URI непрозрачны, поэтому соблюдение того, что части его являются "действительными", а другие не имеют никакого смысла с точки зрения клиента. Поэтому вы должны "просто" вернуть 404 клиенту, поскольку ресурс "package/1234/next_checkpoint" не существует.

Ответ 4

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

Обновление: при дальнейшем чтении RFC "procondition failed" предназначен для условных заголовков, таких как "if-none-match". Вместо этого я давал бы общее сообщение 400.

Ответ 5

Собственно, вы не должны этого делать. Ваше использование 404 Not Found верное, но 400 Bad Request используется неправильно. A 400 Bad Request в соответствии с RFC используется только в том случае, если протокол HTTP имеет неправильный характер. В вашем случае запрос синтаксически правильный, это просто неожиданный аргумент. Вы должны вернуть 500 Server Error, а затем включить код ошибки в свой результат REST.