Надлежащее использование Кодов состояния HTTP в сервере “проверки”

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

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

Фальшивка Отношений

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

Это - своего рода позор и двойной стандарт, все же. Много приложений используют Аутентификацию HTTP, и они могут возвратить HTTP 401, Не Авторизованный или 403 Запрещенных от прикладного уровня. Это было бы удобно и разумно иметь своего рода общий HTTP 4xx Запрос, Отклоненный, что Вы могли использовать.

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

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

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

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

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

POST /validator 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 будет уместен только в случае синтаксических проблем с загрузкой основной формы.