Обработка ошибок в Rest

Question

Существует много способов обработки ошибок в RESTful api: s. Упрощение решения иногда требует наличия системных требований и политики домена. Stack Overflow делает упрощение с помощью своего собственного api, используя код состояния http 400 для всех ошибок (https://api.stackexchange.com/docs/errors), а затем встраивает свои собственные коды ошибок в ответ.

Это решение, которое выполняет шаблон REST, но, вероятно, имеет другие преимущества. Одно из преимуществ, о котором я могу думать, состоит в том, что коды ошибок в ответе могут быть более системными, чем использование только ошибок, доступных в протоколе http. Есть ли еще преимущества использования шаблона Stackoverflow для обработки ошибок REST?

Answer 1

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

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

Вот что я обычно используют (описано с использованием формата JSON, но это не связано с определенным форматом):

{ 
    errors: [ 
    { 
     "message": "my message", 
     "code": "ERR12", 
    }, 
    { 
     "message": "my message", 
     "code": "ERR13", 
     "field": "fieldName" 
    } 
    ] 
} 

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

Кроме того, я думаю, что мы можем использовать другие коды 4xx, так как код 400 является немного общим. Вот некоторые, чем можно было бы использовать:

• 400: общая ошибка говорит запрос не является правильным
• 405: если вы пытаетесь использовать метод HTTP, который не поддерживается ресурсом
• 409: ошибка с Оптимистической блокировкой
• 412: если предварительные условия не в состоянии перед выполнением обработки методы ресурса
• 415: если формат предоставленного представления не кор rect или запрошенный тип носителя не поддерживается
• 422: ошибка при проверке входного представления. Если вы используете WebDAV, вы можете использовать его (см., Например, API Github).

Вы можете заметить, что некоторые из этих методов (405, 415) значения поддерживаются рамками REST (например Restlet).

В контексте Restlet управление ошибкой может быть выполнено, как описано в этом ответе: JSON Representation of a HTTP 400 for Restlet Client. Это может дать вам некоторые подсказки для вашей реализации даже без этой структуры.

Надеюсь, это поможет, Thierry