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

Question

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

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

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

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

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

GET / package / 1234 / next_checkpoint возвращает 400 Плохой запрос , если «next_checkpoint» и 1234 действительны для запроса, но next_checkpont здесь не делает чувство ...

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

POST / dispatch /? For_package = 1234 возвращает 412 Не выполнено предварительное условие , если / dispatch и пакет 1234 существуют, НО 1234 еще не готов к отправке.

---

( Редактировать: Коды состояния в HTTP / 1.1 и Коды состояния в WebDAV ext. )

Answer 1

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

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

Jan

Answer 2

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

Answer 3

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

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

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

Answer 4

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

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

Answer 5

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