REST: Отображение ошибок приложения к кодам состояния HTTP
Это нужно считать хорошей практикой для многократного использования кодов состояния HTTP RFC как это, или мы должны составлять новые, которые отображаются точно на наши определенные ошибочные причины?
Мы разрабатываем веб-сервис API на основе нескольких унаследованных приложений.
В дополнение к структурам данных JSON/XML в Органе по Ответу мы стремимся возвращать коды состояния HTTP, которые имеют смысл к веб-кэшам и разработчикам.
Но как Вы идете об отображении различных классов ошибок на соответствующие коды состояния HTTP? Все в команде договариваются о следующем:
ДОБЕРИТЕСЬ/package/1234 возвращается 404 Не Найденный, если 1234 не существует
ДОБЕРИТЕСЬ/package/1234/next_checkpoint возвращает 400 Плохих Запросов, если "next_checkpoint" и 1234 допустимы для просьбы, но next_checkpont здесь не имеет смысла...
и так далее..., но, в некоторых случаях, вещи должны быть более конкретными, чем всего "400" - например:
POST / диспетчеризирует/? for_package=1234 возвращает 412 Предварительных условий, Неудавшихся, если отправка / и пакет, 1234 оба существует, НО 1234 просто еще не готов к отправке.
(Редактирование: Коды состояния в HTTP/1.1 и Коды состояния в расширении WebDAV)
5 ответов
Полное использование HTTP в REST означает, что вы должны поддерживать единообразие API. Это означает, что вы не можете добавлять методы, специфичные для домена (например, GET_STOCK_QUOTE), но это также означает, что вы не можете добавлять коды ошибок, специфичные для домена (например, 499 Product Out Of Stock).
Фактически, коды ошибок HTTP-клиента являются хорошей проверкой проекта, потому что, если вы правильно спроектируете семантику своего ресурса, значения кода ошибки HTTP будут правильно выражать любые ошибки. Если вы чувствуете, что вам нужны дополнительные коды ошибок, вероятно, ваш дизайн ресурса неверен.
Янв
На самом деле, вам вообще не следует этого делать. Вы используете 404 Not Found правильно, но 400 Bad Request используется неправильно. 400 Bad Request согласно RFC используется только тогда, когда протокол HTTP имеет неправильный формат. В вашем случае запрос синтаксически правильный, это просто неожиданный аргумент. Вы должны вернуть 500 Ошибка сервера , а затем включить код ошибки в результат REST.
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.
422 Unprocessable Entity - полезный код ошибки для подобных сценариев. См. Этот вопрос , какой HTTP-код ответа для службы отдыха при методе размещения, когда правила домена недействительны , для получения дополнительной информации.