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

Среди данных, которые мое приложение отправляет на сторонний SOA-сервер, - сложные XML-файлы. Владелец сервера предоставляет схемы XML ( .xsd), и, поскольку сервер отклоняет недопустимые XML с помощью бессмысленного сообщения, мне нужно проверить их локально перед отправкой.

Я мог бы использовать автономный валидатор XML-схемы, но они медленные, в основном из-за времени, необходимого для разбора файлов схемы. Поэтому я написал свой собственный валидатор схемы (на Java, если это имеет значение) в виде HTTP-сервера, который кэширует уже проанализированные схемы.

Проблема в том, что в процессе валидации многие вещи могут пойти не так. За исключением неожиданных исключений и успешной проверки:

  • сервер может не найти указанный файл схемы
  • указанный файл не может быть допустимым файлом схемы
  • XML недопустим в отношении файла схемы

Поскольку это HTTP-сервер, я хотел бы предоставить клиенту значимые коды состояния . Должен ли сервер ответить с ошибкой 400 ( неверный запрос ) для всех вышеперечисленных случаев? Или они не имеют ничего общего с HTTP, и он должен ответить 200 с сообщением в теле? Любое другое предложение?

Обновление : основное приложение написано на Ruby , у которого нет хорошей библиотеки проверки схемы XML, поэтому отдельный сервер проверки не перегружен.

12.12.2008 12:31:57
7 ОТВЕТОВ
РЕШЕНИЕ

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

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

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

  • 200: содержимое XML является действительным
  • 400: содержимое XML не было правильно сформировано, заголовок был непоследовательным, запрос не соответствовал синтаксису RFC 2616
  • 401: схема не была найдена в кэше, и серверу нужны учетные данные для использования для аутентификации на стороннем сервере SOA для получения файла схемы
  • 404: файл схемы не найден
  • 409: содержимое XML недопустимо для указанной схемы
  • 412: указанный файл не является допустимой схемой XMl
  • 500: любое непредвиденное исключение на вашем сервере проверки (NullPointerExceptions и др.)
  • 502: схема не была найдена в кэше, и попытка запросить ее у стороннего сервера SOA не удалась.
  • 503: сервер проверки перезапускается
  • 504: см. 502 с причиной = время ожидания
15
15.12.2008 14:13:00
Будьте осторожны при использовании http-статусов, таких как 401, 409 и 412 - они имеют особое значение в протоколе HTTP и не являются кодами, которые вы можете просто использовать в сценарии обобщенной ошибки, потому что вам нравится, как звучит формулировка :) '422 непроцессируемая сущность - это, вероятно, то, что вы ищете в качестве универсального объекта, «хотя она была синтаксически допустимой для ее типа носителя, мы не смогли учесть семантику отправленной сущности запроса» tools.ietf.org/html/rfc4918# раздел-11.2
Matt 28.05.2010 10:36:50

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

2
12.12.2008 12:36:15

From w3c: 400 = Сервер не смог понять запрос из-за неправильного синтаксиса.

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

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

3
12.12.2008 12:52:06

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

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

-1
12.12.2008 13:32:12
Если у вас 200 и дополнительный заголовок для успеха, вы туннелируете протокол по HTTP вместо правильного использования HTTP. Не делай этого.
Julian Reschke 17.04.2010 07:19:53

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

5
17.04.2010 01:56:21

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

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

28
17.04.2010 07:23:23
Обратите внимание, что 422 является специфическим расширением WebDAV. Код состояния 400 будет более подходящим.
Tom Christie 4.06.2013 15:47:43
Это расширение, определенное в WebDAV, но все еще общий код состояния HTTP.
Julian Reschke 5.06.2013 06:09:05

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

POST / валидатор Тип контента: application / xml

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

Если он синтаксически анализируется как тип носителя, в котором он был представлен, но он не проверяется по какой-либо требуемой схеме, или имеет иную семантику, которая делает его недоступным для обработки ресурсом, которому он передается - тогда 422 Непроцессируемый объект - лучший статус (хотя вы вероятно, должно сопровождаться некоторой более конкретной информацией об ошибке в ответе об ошибке, также обратите внимание, что она технически определена в расширении HTTP, WebDAV, хотя довольно широко используется в API-интерфейсах HTTP и более подходит, чем любой из других статусов ошибок 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
28.05.2010 11:26:26