Ошибка SOAP или объект результатов?

Ответ 1

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

Тем не менее, возврат ошибки обычно не помогает клиенту:

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

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

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

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

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

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

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

Ответ 2

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

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

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

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

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

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

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

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

• SOAPFaults, превращенные в Exceptions, являются самым верным способом быстродействия.

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

  • Управление исключениями в мире SOA: Ramesh Ranganathan

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

  • Рекомендации по ошибкам SOAP

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

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

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

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

Ответ 3

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

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

Ответ 4

Правило, которое я придерживаюсь в дизайне обслуживания, следующее:

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

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

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