Выбор кодов состояния HTTP для ошибок служб REST-ful

Когда клиент вызывает мою службу REST-ful, он должен знать, вернулся ли ответ, был "от меня" или, скорее, диагноз с содержащего веб-сервера, что произошло что-то ужасное.

Одна из теорий заключается в том, что, если мой код вызывается, он должен всегда возвращать HTTP OK (= 200), и любые ошибки, которые мне нужно вернуть, должны быть представлены только в возвращаемых данных. В конце концов, это мой код, который получает ответ, а не голый браузер.

Несколько очевидным образом, если я использую REST для генерации HTML-кода, читаемого напрямую браузером, я обязательно должен вернуть код ошибки, если есть ошибка. В случае, о котором я забочусь, это всегда Javascript или Java, которые интерпретируют внутренности ответа.

Другая возможность заключается в том, что существует некоторое семейство кодов состояния HTTP, с которыми я мог бы вернуться с высокой уверенностью в том, что они/они никогда не будут генерироваться проблемой в окружающем контейнере. Это тот случай?

Ответы

Ответ 1

Я использую следующее:

GET

  • 200 OK
  • 400 Bad Request (если критерии ввода неверны)

POST

  • 202 Принято (возвращается методом авторизации)

  • 401 Несанкционированный (также возвращенный авторизацией)

  • 201 Создан (при создании нового ресурса, я также устанавливаю заголовок местоположения)

  • 400 Bad Request (когда данные для создания нового объекта недействительны или откат транзакций)

PUT

То же, что и POST

  • 201 Ok
  • 400 Bad Request

DELETE

  • 200 OK
  • 404 Не найдено (аналогично GET)

Ответ 2

Я не знаю, как избежать того, что некоторые контейнеры возвращают коды вроде 404.

Коды 4xx предназначены для обработки клиентских ошибок вместе с возможно некоторой сущностью, которая подробно описывает проблему (и, следовательно, будет означать комбинацию обоих ваших упомянутых подходов). Поскольку REST полагается на HTTP и соответствующую семантику статуса, а также методы, всегда возвращающее 200 в любом возможном случае является нарушением этого принципа, на мой взгляд.

Если вы, например, имеете такой запрос, как http://foo.com/bar/123, который представляет bar ressource с id=123, и вы возвращаете 200 с некоторым контентом, у клиента нет никаких шансов выяснить, был ли это предполагаемый ответ или какой-либо какая-то ошибка. Поэтому следует попытаться сопоставить условия ошибки с кодами состояния, как описано в REST: сопоставление ошибок приложений с кодами состояния HTTP.