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

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

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

Янв

422 Unprocessable Entity - полезный код ошибки для подобных сценариев. См. Этот вопрос https://stackoverflow.com/questions/2190945/what-http-response-code-for-rest-service-on-put-method-when-domain-rules-invalid/2194786#2194786 для получения дополнительной информации.

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

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

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

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

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

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