Как справиться с исключениями REST?

Мы находимся в середине продолжающейся дискуссии о том, как обрабатывать исключения REST.Как справиться с исключениями REST?

Response Тип содержимого: JSON

Два решения мы имеем:

Выбросьте все непроверенные исключения в качестве ответа JSON.
Отправить запрос Неверный код ответа.

Аргументы:

Когда его ошибка, почему вернуть JSON? Просто отправьте неверный код ответа.

контраргумент:

Код ответа слишком технический для обработки для обычных разработчиков.

Что вы говорите ??

источник

2010-06-25 Vanchinathan Chandrasekaran

Интересно, почему коды ответов слишком технические. Если вы должны/можете предпринять какие-либо корректирующие действия, вы должны зависеть от кода ответа (или любого другого кода ошибки внутри json), а не от читаемых пользователем строк ошибок. –

Мы имеем дело со всеми видами клиентов. Поэтому мы не хотим предполагать, что разработчики с клиентами достаточно владеют, чтобы понимать коды ответов. Это были мысли людей и моих людей. Если они смотрят на json, они могут понять ошибку. –

Одним из основных преимуществ REST является единообразие интерфейсов. Поэтому, когда вы говорите, что у нас есть REST api, клиент автоматически ожидает список ресурсов и операции GET PUT POST DELETE, а также знает коды ошибок, которые он может себе представить. Строки ошибок определенно будут полезны для вашего клиента (разработчиков) для отладки. Но код, который они пишут против вашего api *, должен * принимать действия на основе кодов, а не строк. –

Для JSON API, который я недавно разработал, я делаю оба. Я всегда отвечаю действительным JSON (ну, полагая, что я вообще отвечаю). Если я обнаруживаю неверный запрос, я использую статус 400. Если я обнаруживаю ошибку сервера (которая, как я полагаю, не вызвана недопустимым запросом), я использую статус 5xx. Объект JSON содержит специальный ключ, который установлен только для ошибок со строковым значением.

Я думаю, что это хорошее решение, которое уважает принципы REST и может использоваться несколькими способами. Это же решение используется некоторыми другими API-интерфейсами JSON, такими как Yahoo Search. Попробуйте http://search.yahooapis.com/ImageSearchService/V1/imageSearch?appid=YahooDemo&output=json.

источник

2010-06-25 21:46:30

+1: При использовании RESTful HTTP вы абсолютно должны использовать коды ответа HTTP.Дополнительная информация может быть возвращена в представлении. –

Я только что увидел этот ответ в «Связанных» вещах SO. И хотя его старый ответ, очевидно, все еще проявляется. Я считаю, что есть большая проблема с хорошей обработкой ошибок, чем просто использование кодов состояния HTTP (это хороший старт!). См. Http://soabits.blogspot.dk/2013/05/error-handling-considerations-and-best.html для углубленного обсуждения. –

Используйте коды ошибок, например, для HTTP. Таким образом, 50 * для любого исключения вызывают некоторые внутренние проблемы. И 40 * за плохие аргументы. Избегайте использования ваших собственных определенных кодов, насколько это возможно. Идея состоит в том, чтобы иметь «единый» интерфейс.

В целом. 204 для успеха без отправки содержимого 200 для успеха с json-представлением ресурса И если его успешная операция не возвращает соответствующий код ответа. Вы можете выбрать опцию возврата json. Чтобы упростить вещи, вы можете иметь общий формат (json) для всех ответов об ошибках.

http://en.wikipedia.org/wiki/REST необходимо прочитать, прежде чем замораживать свои спецификации api.

источник

2010-06-25 22:07:01

«201 за успех без отправки какого-либо контента». 201, поэтому его следует использовать только тогда, когда «новый ресурс создан», а не для общего успеха. Возможно, вы думаете о 204, «Без содержания» –

oops! правильно. спасибо за исправление! –

Как справиться с исключениями REST?

ответ

Смежные вопросы