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

Ответ 1

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

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

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

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

Ответ 2

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

"Код статуса 422 (Unprocessable Entity) означает, что сервер понимает тип содержимого объекта запроса (следовательно, код статуса 415 (неподдерживаемый тип носителя) является неуместным), и синтаксис объекта запроса является правильным (таким образом, 400 (неверный запрос) является неприемлемым), но не смог обработать содержащиеся в нем инструкции. Например, это условие ошибки может возникнуть, если тело запроса XML содержит правильно сформированные (т.е. Синтаксически правильные), но семантически ошибочные инструкции XML."

Ответ 3

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

Ответ 4

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

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

Если объект запроса не может разбираться в качестве типа носителя, который был отправлен как (например, как приложение /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 было бы приемлемо только в случае синтаксической проблемы с отправкой основной формы.

Ответ 5

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

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

Отношения Поддельный

Ответ 6

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

Ответ 7

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