Неисправности SOAP или объект результатов?

Question

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

Когда я должен возвращать ошибку SOAP , а когда я должен возвращать объект результата с информацией об ошибке? Предположим, это для общего веб-сервиса, который может использоваться различными системами (.NET, Java и т. Д.). Полученный объект будет иметь флаг isError, errorType (аналогичный конкретному типу исключения) и сообщение.

Некоторые моменты для рассмотрения:

1. Ошибка проверки данных - ошибка?
2. Должна ли быть комбинация ошибок (для очень исключительных случаев) и объекта результатов (для "ожидаемых" ошибок)?
3. Как бы вы сгруппировали ошибки SOAP (критические [нулевая ссылка] против проверки [неверный почтовый индекс])?
4. Отказоустойчивость против необходимости помнить для проверки на ошибку
5. Лучшие практики, шаблоны, стандарты и т. Д.

Ссылки на статьи действительны. Даже если это звучит так, как будто я хочу узнать ваше мнение, пожалуйста, придерживайтесь фактов (x лучше из-за y и z ...)

Answer 1

Большинство клиентов SOAP преобразуют ошибки в исключение времени выполнения (если это то, что поддерживает язык клиента). Имея это в виду, я думаю, что вы могли бы перефразировать вопрос как «Когда я хочу выдать исключение вместо возврата значения ошибки»? Я уверен, что вы можете найти много мнений об этом дизайне API в целом и этой теме в частности.

Тем не менее, возвращение ошибки обычно бесполезно для клиента:

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

2. Если вы не включили свои коды ошибок в WSDL; у клиента не будет документации о том, кем он является или когда он происходит. Типичные ошибки являются частью WSDL и, следовательно, (в некоторой степени) самодокументируются.

3. Сообщения о сбоях могут содержать специфический для сбоя контекст, который клиент может использовать для отчетов об ошибках и восстановления. Например, выдает ошибку проверки ввода, содержащую фактический недопустимый элемент ввода и причину. Если вы возвращаете результат с кодом ошибки и непрозрачной строкой, у клиента не остается иного выбора, кроме как передать ваше сообщение об ошибке пользователю, что нарушает интернационализацию, согласованность пользовательского интерфейса и т. Д.

Чтобы ответить на ваши конкретные вопросы:

1. Ошибка проверки является ошибкой. Представьте, что вы вызываете веб-сервис из клиента AJAX с ограниченными возможностями обработки ошибок; вы хотите, чтобы служба возвращала HTTP-код 5xx, а не код успеха 400 с неожиданным ответом.

2. Нет. API должны обеспечивать согласованные интерфейсы отчетов об ошибках. WSDL-дизайн - это API-дизайн. Принуждение клиента к реализации двух различных обработчиков ошибок не облегчает жизнь клиента.

3. Проект ошибки должен отражать вашу модель запроса / ответа и отображать информацию, соответствующую абстракции службы. Не создавайте ошибку NullReference; спроектировать XYZServiceRuntimeFault. Если клиенты часто предоставляют недопустимые запросы, разработайте InvalidRequestFault с соответствующими подклассами, чтобы клиенты могли быстро выяснить, где находятся недопустимые данные.

Answer 2

Объект результатов должен содержать только результаты. Если ваш объект результата предоставляет список ошибок, которые произошли в другой системе, то это пример того, когда вы можете иметь и флаг "isError"; в противном случае вы не сможете этого сделать, потому что результат либо действителен, либо нет.

При возникновении ошибки всегда следует использовать SOAPFault. Валидация - это ошибка, и дьявол сам по себе считает, что валидация менее серьезна, чем невозможность открыть базу данных. Оба случая имеют одинаковое влияние - операция не может быть завершена в соответствии с запросом.

Таким образом, вы должны использовать объекты результатов для результатов и ошибки SOAP для всего, что мешает действительному объекту результатов; включая, помимо прочего, ошибки, сбои валидации, предупреждения, сбои шины и т. д.

В дни, предшествующие исключениям, выбора не было, и в результате многие API стали непоследовательными, и большинство API различалось в том, как вернуть ошибку. Это было (и остается) ужасно, сбивает с толку и часто замедляет разработку, потому что вам нужно посмотреть, как каждая запись API возвращает ошибку, и часто, как декодировать или узнать больше об ошибке.

1. Обрабатывать проверку с помощью SOAPFaults / Exceptions более логично, когда вы думаете об этом, и, как только вы подумали об этом, обычно проще. Вам необходимо спроектировать класс ошибок проверки так, чтобы он содержал достаточную информацию для идентификации нарушающих элементов способом, не обязательно требующим первоначального запроса. Таким образом, вы можете начать обрабатывать ошибки проверки более обобщенно.

2. Если объект результатов содержит ошибки, они могут быть только в пределах области результатов; например, Товар отсутствует на складе , поскольку кто-то из склада не может сосчитать, находится в области контроля инвентаря.

3. Не имеет смысла проводить различие между критической ошибкой и ошибкой проверки, это, на мой взгляд, не является достоверным сравнением, поскольку любое присвоение уровня серьезности является очень субъективным. Например, в системе, предоставляющей информацию о химических веществах для пожарного, критическое значение, вероятно, означает, что пожарный грузовик несет ООН 1298 и ООН 1436, а не нулевую ссылку при попытке загрузить графическое предупреждение.

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

4. SOAPFaults, превращенные в Исключения, являются самым надежным способом быстрого отказа.

5. Лучшие практики, ссылки и т. Д.

   • Управление исключениями в мире SOA: Рамеш Ранганатан

   • Когда исключение составляет правило: создание надежных и прослеживаемых сервис-ориентированных архитектур

   • Лучшие практики по ошибкам SOAP

   • Использование ошибок SOAP для предоставления соответствующего уровня детализации разработчику во время разработки и заказчику во время работы веб-службы.

   • Веб-службы используют ошибки SOAP, чтобы сообщать о случаях ошибок клиентам. Сбои могут быть сгенерированы из инфраструктуры SOAP в случае недопустимых сообщений SOAP, недопустимых маркеров безопасности или они могут быть сгенерированы из самой бизнес-логики сервиса

   • Если вы отправили сообщение, которое по какой-то причине не было успешным, вы можете получить ответ, содержащий элемент ошибки SOAP, в котором содержится информация о состоянии, информация об ошибке или и то и другое. В сообщении может быть только один элемент ошибки SOAP, и это должна быть запись в теле SOAP. Кроме того, если в теле SOAP есть элемент ошибки SOAP, в теле SOAP не может быть других элементов. Это означает, что когда вы добавляете элемент ошибки SOAP, вы фактически завершили создание тела SOAP.

   • Сообщения об ошибках SOAP - это механизм, с помощью которого приложения SOAP сообщают об ошибках «в восходящем направлении» узлам, ранее находящимся в пути сообщения. Задача этого раздела - дать полное и подробное объяснение сбоев SOAP, чтобы вы могли соответствующим образом обрабатывать их в своих собственных веб-сервисах.

Answer 3

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

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

Answer 4

Правило, которому я следую в сервисном дизайне:

• бизнес-уровень ответ (даже бизнес-исключения) на объекты ответа
• технический / уровень интеграции сбои в Soap Fault

Потребитель услуг может полагаться на то, что все виды бизнес-ответов поступают в объектах ответов и представляют их сервисным (бизнес) пользователям. Неисправности мыла используются только тогда, когда бизнес-ответ не может быть доставлен.

Неисправности мыла должны вызывать предупреждение поддержки / действие посредством мониторинга.