Отказы SOAP или объект результатов?
У меня была дискуссия об этом с коллегой, и мы не могли прийти к соглашению, таким образом, я хотел получить Ваши мысли. У меня есть свои собственные мнения об этом, но я не испорчу его для Вас.
Когда я должен возвращать ошибку SOAP и когда я должен возвращать объект результата, который имеет информацию об ошибке? Предположите, что это для универсального веб-сервиса, который может быть использован различными системами (.NET, Java, безотносительно). Объект результата имел бы флаг isError, errorType (подобный определенному типу исключительной ситуации), и сообщение.
Некоторые вопросы для рассмотрения:
- Действительно ли ошибка подтверждения правильности данных является отказом?
- Должна быть комбинация отказов (для очень исключительных случаев) и объект результатов (для "ожидаемых" ошибок)?
- Как Вы сгруппировали бы отказы SOAP (очень важный [нулевая ссылка] по сравнению с проверкой [почтовый индекс, неправильный])?
- Сбой быстро по сравнению с необходимостью не забыть проверять на ошибку
- Лучшие практики, шаблоны, стандарты, и т.д.
Ссылки на статьи действительны. Даже при том, что это кажется, что я хочу Ваше мнение, придерживайтесь фактов (x, лучше из-за y и z...),
3 ответа
Большинство клиентов SOAP преобразуют сбои в исключение времени выполнения (если это поддерживается языком клиента). Имея это в виду, я думаю, вы могли бы перефразировать вопрос как «Когда я хочу генерировать исключение вместо того, чтобы возвращать значение ошибки»? Я уверен, что вы можете найти множество мнений об этом дизайне API в целом и по этой теме в частности.
Тем не менее, возврат ошибки обычно бесполезен для клиента:
Клиенту необходимо вручную перечислить и обработать ваши коды ошибок, вместо того, чтобы позволять коду заглушки генерировать и выдавать исключение соответствующего типа. Использование кодов ошибок не позволяет клиенту использовать объектно-ориентированные методы, такие как обработка исключений суперклассом.
Если вы не включаете коды ошибок в WSDL; у клиента не будет документации о том, что они собой представляют и когда они происходят. Типизированные ошибки являются частью WSDL и поэтому (в некоторой ограниченной степени) самодокументируются.
Сообщения об ошибках могут содержать конкретный контекст сбоя, который клиент может использовать для сообщения об ошибках и восстановления. Например, выдача ошибки проверки ввода, содержащей действительный недопустимый элемент ввода и причину. Если вы возвращаете результат с кодом ошибки и непрозрачной строкой, у клиента нет другого выбора, кроме как передать ваше сообщение об ошибке пользователю, что нарушает интернационализацию, согласованность пользовательского интерфейса и т. Д.
Чтобы ответить на ваши конкретные вопросы:
] Ошибка проверки является ошибкой.Представьте, что вы вызываете веб-службу из клиента AJAX с ограниченными возможностями обработки ошибок; вы хотите, чтобы служба возвращала код HTTP 5xx, а не код успеха 400 с неожиданным ответом.
Нет. API-интерфейсы должны обеспечивать согласованные интерфейсы отчетов об ошибках. Дизайн WSDL - это дизайн API. Принуждение клиента к реализации двух отдельных обработчиков ошибок не облегчает жизнь клиента.
Дизайн сбоя должен отражать вашу модель запроса / ответа и отображать информацию, соответствующую абстракции службы. Не создавайте ошибку NullReference; создать XYZServiceRuntimeFault. Если клиенты часто предоставляют недопустимые запросы, создайте InvalidRequestFault с соответствующими подклассами, чтобы клиенты могли быстро определить, где находятся недопустимые данные.
Объект результатов должен содержать только результаты. Если ваш объект результата предоставляет список ошибок, которые произошли в другой системе, то это пример того, когда вы можете иметь и флаг «isError»; в противном случае вы не можете, потому что результат либо действителен, либо нет.
При возникновении ошибки всегда следует использовать SOAPFault. Валидация - это ошибка, и это чертовски ловушка думать о валидации как о менее серьезной проблеме, чем невозможность открыть базу данных. Оба случая имеют одинаковое влияние - операция не может быть завершена в соответствии с запросом.
Таким образом, вы должны использовать объекты результатов для результатов и Ошибки SOAP для всего, что препятствует получению действительного объекта результата; включая, но не ограничиваясь этим, ошибки, сбои проверки, предупреждения, сбои шины и т. д.
В дни, предшествовавшие исключениям, не было выбора, и в результате многие API-интерфейсы стали несовместимыми, и большинство API-интерфейсов различались по способам возврата ошибки. Это было (и остается) ужасно, сбивает с толку и часто замедляет разработку, потому что вам нужно искать, как каждая запись API возвращает ошибку, и часто, как декодировать или узнать больше об ошибке.
Обработка валидации с помощью SOAPFaults / Exceptions более логична, когда вы думаете об этом, и, как только вы подумали об этом, обычно проще. Вам необходимо спроектировать класс ошибок проверки так, чтобы он содержал достаточную информацию для идентификации проблемных элементов способом, не обязательно требующим исходного запроса. Таким образом, вы можете начать обрабатывать ошибки валидации в более общем плане.
Если объект результатов содержит ошибки, они могут находиться только в области результатов; например Товар отсутствует , потому что кто-то на складе не может подсчитать, находится в области управления запасами.
Неразумно проводить различие между критической ошибкой и ошибкой проверки, это, на мой взгляд, неверное сравнение, потому что любое присвоение уровня серьезности очень субъективно. Например, в системе, предоставляющей информацию о химикатах пожарному, критическое, вероятно, означает, что пожарный грузовик несет номер ООН 1298 и ООН 1436, а не пустую ссылку при попытке загрузить графику предупреждения.
Проектируйте неисправности таким образом, чтобы их можно было кратко идентифицировать и обрабатывать соответствующим образом. Убедитесь, что они передают достаточно информации. Аббревиатура категоризации - это то, что не имеет смысла, когда у вас достаточно информации, потому что Неисправность позволяет идентифицировать себя.
Преобразование SOAPFaults в исключения - это самый надежный способ добиться быстрого сбоя.
Лучшие практики, ссылки и т. Д.
Я думаю, что короткий ответ - использовать ошибку мыла, если вы не знаете, что клиент будет готов обработать ошибку, возвращаемую в качестве результата. Я также подумал об аналогии между исключениями и результатами ошибок, как упоминалось в других ответах.
Существуют серые области, которые можно разумно рассматривать и как исключения, и как ошибки результата, в зависимости от потребностей клиента. Вы можете предоставить параметр службе, который изменяет способ возврата этих типов ошибок. По умолчанию используется ошибка SOAP, но если клиент задает параметр для получения результатов ошибки, то это означает, что он готов обрабатывать это как часть результата. Для меня ошибки валидации находятся в этой серой зоне. Для большинства клиентов они должны считаться ошибками, но если клиент хочет использовать данные для разметки пользовательского интерфейса с ошибками валидации, то возврат ошибок валидации как часть результата может быть более полезным.