Лучший способ вернуть сообщения об ошибках в сервисах REST?

Я рассматривал примеры REST API, такие как Netflix http://developer.netflix.com/docs/REST_API_Reference#0_59705 и Twitter, и они, похоже, размещают сообщения об ошибках в заголовке statusText вместо ответа. Мы разрабатываем внутренний RESTful api, и я спорю о передаче пользовательских сообщений statusText и игнорировании responseText.

В рамках нашего приложения мы возвращаем ошибку 400, когда пользователь попытался сделать то, чего они не должны, и единственные сообщения об ошибках, которые будут обновлены в пользовательском интерфейсе для пользователя, будут доставлены с 400 Я полагаю, что сообщение должно быть отправлено как измененный statusText, но один из инженеров (кто знает немного меньше о REST, чем я) утверждает, что отправил его в responseText.

Какой лучший способ пойти?

Ответ 1

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

В общем, попробуйте сопоставить свои ошибки с существующими ошибками HTTP, например, если они запрашивают то, на что у них нет разрешения, вернуть ошибку 403.

Если они запрашивают то, что не существует, верните 404.

Alex

Ответ 2

HTTP определяет, что вы должны поместить описательное сообщение об ошибке в тело объекта ответа, aka responseText.

statusText не обрабатывается и не обрабатывается каким-либо клиентом.

Я бы использовал текст состояния для типа сообщения об ошибке, например 400 Client Error, и тело для описания проблемы, которая может быть предоставлена пользователю, в любом формате, который клиент может обработать.

Изменить: обратите внимание, что с тех пор существует новый стандартизованный формат для связи в стандартной информации о моде, возвращаемой клиенту, которую вы можете найти в https://tools.ietf.org/html/rfc7807 и который я бы рекомендовал.

Ответ 3

В соответствии со спецификацией HTTP (rfc2616): "Коды состояния HTTP являются расширяемыми"

Однако я не думаю, что создание новых статусов для каждого сообщения об ошибке является правильным:

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

Ответ 4

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

Тело объекта должно быть представлением состояния ресурса и в идеале содержать гиперссылки на доступные следующие состояния в вашем приложении

Ответ 5

Коды состояния HTTP довольно понятны и должны использоваться как таковые. Возвращение 200 OK с ошибками проверки является довольно Soap-y и вводит в заблуждение. Любая ошибка REST Client 4xx и 5xx попадают в блок ошибок, и это действительно зависит от случая к случаю, если вы действительно хотите использовать тело ответа для ответов без 2xx.