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

Question

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

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

Некоторые моменты, которые следует учитывать:

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

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

Answer 1

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

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

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

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

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

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

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

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

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

Answer 2

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

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

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

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

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

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

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

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

4. Soapfaults превратились в исключения, являются самым верным способом потерпевшего неудачное.

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

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

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

   • Лучшие практики на разломах мыла

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

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

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

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

Answer 3

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

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

Answer 4

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

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

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

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