Правильный способ передачи сообщений об ошибках во время звонков в службу REST?

Question

Я пишу веб-сервис на основе REST и пытаюсь найти лучший способ обработки условий ошибок.

В настоящее время сервис возвращает HTTP-ошибки, такие как Bad Request, но какмогу ли я вернуть дополнительную информацию, чтобы дать разработчикам, использующим веб-сервис, представление о том, что они делают неправильно?

Например: создание пользователя с нулевым именем пользователя возвращает ошибку Bad Request.Как я могу добавить, что ошибка была вызвана нулевым параметром имени пользователя?

Answer 1

Согласно спецификации HTTP , текст, который следует после трехзначного кода ответа, «Фраза-причина», может быть заменен только логическим эквивалентом .Таким образом, вы не можете ответить 400 null user и ожидать, что произойдет что-то полезное.Действительно, От клиента не требуется проверять или отображать фразу-аргумент.

В общем случае объект ответа HTTP (обычно это страница, сопровождающая ответ) должен содержать информациюКлиенту полезно направлять их вперед , даже если ответ является ошибкой.В Интернете большинство таких ошибок являются HTML и лишены машиночитаемой информации, но большинство браузеров действительно отображают ошибку пользователю (и страница ошибок SO довольно хороша!).

Таким образом, для ресурса, который в основном предназначен для чтения с компьютера, у вас есть два варианта:

1. В любом случае передать сообщение, читаемое человеком.Верните 400 Bad Request с ответом в формате HTML, который клиент может показать пользователю.Это очень просто, но это немного , как если бы выбрасывалось непроверенное исключение , оно передает всю тяжелую работу клиенту или конечному пользователю.
2. Разрешить клиентам восстановление.Верните 400 Bad Request с машиночитаемым ответом, который является частью вашего API, чтобы клиенты могли восстанавливаться после известных ошибок.Это сложнее, подобно генерации проверенного исключения, становится частью API и позволяет клиентам корректно восстанавливаться, если они этого хотят.

Вы даже можете сделать серверПоддержите оба сценария, определив тип носителя для машиночитаемого восстановления после ошибок документа и разрешив клиентам «принимать» их: Accept: application/atom+xml, application/my.proprietary.errors+json

Клиенты, которые забыли обязательное поле, могут выбратьполучение машиночитаемых ошибок или ошибок, читаемых человеком, выбрав Accept тип носителя с ошибкой.

Answer 2

В спецификации HTTP указано, что большинство кодов ошибок должно возвращать некоторый базовый текст, который объясняет, почему возвращается ошибка. Для этой цели базовая спецификация сервлета Java определяет HttpServletResponse.sendError(int Code, String message).

Answer 3

String desc = "my Description";
throw new WebApplicationException(Response.status(Status.BAD_REQUEST).entity(desc).type("text/plain").build());