Какова наилучшая практика для серверов SOAP по внедрению уведомлений об ошибках?

Я разрабатываю некоторые веб-службы SOAP с использованием Ruby on Rails и обдумываю, как обрабатывать общие сбои. Эти общие ошибки применимы ко всем методам службы и включают следующее:

  • Отсутствует элемент запроса
  • Отсутствует элемент аутентификации (Пользовательский)
  • Неверные данные аутентификации

Я могу перехватить эти ошибки в своем контроллере перед вызовом соответствующего метода и отреагировать соответствующим образом. Мой вопрос заключается в том, какой реализацией проще всего управлять с точки зрения клиента. Мои варианты обработки этих ошибок выглядят следующим образом.

  1. Создайте исключение и позвольте службе SOAP создать SoapFault. Это было бы хорошо, за исключением того, что у меня мало (нет) контроля над структурой сообщения, содержащегося в ошибке SOAP.
  2. Верните ответ Http 400 с согласованной структурой данных, чтобы указать сообщение об ошибке. Однако эта структура не будет определена в WSDL.
  3. Включайте элемент состояния во все ответы, независимо от того, успешны они или нет, и пусть этот элемент состояния включает код и массив данных об ошибках (включая сообщения об ошибках).

Третий вариант кажется лучшим решением, но он также наиболее подвержен ошибкам при реализации, поскольку реализация веб-сервисов в ROR не позволяет мне реализовать это в общем виде, и каждый метод становится ответственным за проверку результатов проверок и предоставление соответствующего ответа. . По общему признанию, это будет один вызов функции и возврат в случае сбоя, но он полагается на то, что разработчик не забудет сделать это, когда мы добавим больше параметров.

Я ценю то, что большинство разработчиков ROR скажут, что это должно быть реализовано как служба REST, и я согласен, на самом деле у нас уже есть службы REST для этого, но распространение SOAP в корпоративном мире и его впечатляющая инструментальная поддержка означают, что у нас есть предоставлять услуги SOAP, чтобы оставаться конкурентоспособными.

По вашему опыту, что было бы самой простой реализацией для клиентов, и зависит ли это от библиотек/языка клиентского процесса.


person Steve Weet    schedule 22.06.2010    source источник


Ответы (1)


SoapFault был бы предпочтительным способом обозначения ошибок. SoapFaults может содержать дополнительную информацию в своем элементе <detail>.

Преимущество SoapFault по сравнению с некоторым элементом состояния заключается в том, что вызывающий объект может использовать стандартную обработку исключений вместо проверки какого-либо поля состояния.

person Sjoerd    schedule 22.06.2010