Выбор кодов состояния HTTP для ошибок из сервисов REST-FUL

Question

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

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

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

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

Answer 1

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

GET

• 200 OK
• 400 Плохой запрос (если критерии ввода неверны)

POST

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

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

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

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

PUT

То же, что POST

• 201 Ok
• 400 Плохой запрос

УДАЛИТЬ

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

Answer 2

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

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

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