Я занимаюсь разработкой некоторых веб-сервисов SOAP с использованием Ruby on Rails и рассматриваю способы обработки общих сбоев.Эти общие ошибки применимы ко всем методам службы и включают в себя следующее: -
- Отсутствует элемент запроса
- Отсутствует элемент аутентификации (Custom)
- Недействительная аутентификациядетали
Я могу перехватить эти ошибки в моем контроллере перед вызовом соответствующего метода и ответить соответствующим образом.Мой вопрос в том, какой реализацией легче всего управлять с точки зрения клиента.Мои варианты обработки этих ошибок выглядят следующим образом.
- Создайте исключение и дайте службе SOAP сгенерировать SoapFault.Это было бы хорошо, за исключением того, что я почти не контролирую структуру сообщения, содержащегося в ошибке SOAP.
- Возвращает ответ Http 400 с согласованной структурой данных, чтобы указать сообщение об ошибке.Эта структура не будет определена в WSDL.
- Включать элемент Status во все ответы, независимо от того, успешны они или нет, и включать в этот элемент состояния код и массив данных об ошибках (включая сообщения об ошибках).
Вариант три кажется лучшим решением, но он также наиболее подвержен ошибкам, поскольку реализация веб-служб в ROR не позволяет мне реализовать это в общем виде, и каждый метод становится ответственным за проверкурезультат проверок и предоставление соответствующего ответа.По общему признанию, это будет один вызов функции и возврат в случае сбоя, но разработчик полагается не забывать делать это, когда мы добавляем больше опций.
Я ценю, что большинство разработчиков ROR скажут, что это должно быть реализовано какREST-сервис, и я согласен, фактически у нас уже есть REST-сервисы для этого, но распространение SOAP в корпоративном мире и его впечатляющая инструментальная поддержка означают, что мы должны предоставлять SOAP-сервисы, чтобы оставаться конкурентоспособными.
По вашему опыту, какая из реализаций для клиентов будет проще всего обрабатывать, и будет ли она отличаться в зависимости от библиотек / языка клиентского процесса.