Правильное использование кодов состояния HTTP на сервере проверки

Сопоставление ошибочных ситуаций в процессе валидации с осмысленными кодами статуса HTTP - совершенно правильная идея.

Я предполагаю, что вы отправляете XML-файл на свой сервер проверки в качестве содержимого POST, используя URI для определения конкретной схемы для проверки.

Итак, вот несколько предложений по отображению ошибок:

• 200: содержимое XML является допустимым
• 400: содержимое XML не было правильно сформировано, заголовок был несогласованным, запрос не соответствовал синтаксису RFC 2616
• 401: схема не найдена в кеше, и серверу требуются учетные данные для использования для аутентификации на стороннем сервере SOA, чтобы получить файл схемы
• 404: файл схемы не найден
• 409: содержимое XML недопустимо для указанной схемы
• 412: Указанный файл не является допустимой схемой XMl.
• 500: любое неожиданное исключение на вашем сервере проверки (NullPointerExceptions и др.)
• 502: схема не найдена в кеше, и попытка запросить ее у стороннего SOA-сервера не удалась.
• 503: сервер проверки перезагружается
• 504: см. 502 с причиной = тайм-аут

Код состояния 422 («Необработанная сущность») звучит достаточно близко:

«Код состояния 422 (Unprocessable Entity) означает, что сервер понимает тип содержимого объекта запроса (следовательно, код состояния 415 (Unsupported Media Type) не подходит), и синтаксис объекта запроса верен (таким образом, 400 (Bad Request), код состояния является неприемлемым), но не смог обработать содержащиеся инструкции. Например, это состояние ошибки может возникнуть, если тело запроса XML содержит правильно сформированные (т. Е. Синтаксически правильные), но семантически ошибочные инструкции XML ».

Amazon можно использовать в качестве модели для сопоставления кодов состояния http с условиями реального уровня приложения: http://docs.amazonwebservices.com/AWSImportExport/latest/API/index.html?Errors.html (см. заголовок Коды состояния Amazon S3)

Предположим, вы отправляете файлы XML на ресурс, например, так:

POST / валидатор Content-type: application / xml

Если объекту запроса не удается проанализировать тип носителя, в котором он был отправлен (например, как application / xml), правильным статусом будет 400 Bad Request.

Если он синтаксически анализирует тип носителя, в котором он был представлен, но он не проверяется на соответствие какой-либо желаемой схеме или имеет другую семантику, которая делает его необработанным ресурсом, которому он был отправлен, то 422 Unprocessable Entity является лучшим статусом (хотя вы вероятно, должен сопровождаться некоторой более конкретной информацией об ошибке в ответе об ошибке; также обратите внимание, что он технически определен в расширении HTTP, WebDAV, хотя довольно широко используется в HTTP API и более уместен, чем любой другой статус ошибки HTTP, когда есть семантическая ошибка с представленной сущностью).

Если он представлен как тип мультимедиа, который подразумевает определенную схему поверх xml (например, как application / xhtml + xml), вы можете использовать 400 Bad Request, если он не проходит проверку на соответствие этой схеме. Но если его типом носителя является простой XML, то я бы сказал, что схема не является частью типа носителя, хотя это немного серая область; Если в XML-файле указана его схема, вы могли бы интерпретировать валидацию как часть синтаксических требований для application / xml.

Если вы отправляете XML-файлы с помощью формы multipart / form или application / x-www-form-urlencoded, вам придется использовать 422 Unprocessable Entity для всех проблем с XML-файлом; 400 будет подходящим только в том случае, если есть синтаксическая проблема с загрузкой основной формы.

От w3c: 400 = Запрос не может быть понят сервером из-за неправильного синтаксиса.

Я бы не стал его обслуживать, если бы сервер действительно не мог понять запрос. Если вы просто получаете недействительный xml, подайте 200 и объясните, почему что-то не работает.

С уважением Подделка

Я бы пошел с 400 Bad request и более конкретным сообщением в теле (возможно, с дополнительным кодом ошибки в заголовке, например X-Parse-Error: 10451 для упрощения обработки)

Звучит как отличная идея, но коды состояния HTTP на самом деле не обеспечивают случай «сбой операции». Я бы вернул HTTP 200 с заголовком X-Validation-Result: true/false, используя тело для любого текста или «причины» по мере необходимости. Сохраните HTTP 4xx для ошибок уровня HTTP, а не ошибок уровня приложения.

Хотя это своего рода позор и двойные стандарты. Многие приложения используют HTTP-аутентификацию, и они могут возвращать HTTP 401 Not Authorized или 403 Forbidden на уровне приложения. Было бы удобно и разумно иметь какое-то одеяло HTTP 4xx Request Rejected, которое вы могли бы использовать.