Обратная совместимость и веб-сервисы

Question

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

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

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

Answer 1

WSDL на самом деле действует скорее как контракт, чем как интерфейс.WSDL точно описывает, что ожидает "получить" операция и что она ожидает "вернуть".Ближайшей аналогией этому было бы в C изменение прототипа функции без изменения самой функции, они не будут совпадать, и это вызывает проблемы.

Чем более конкретным является WSDL, тем большее поведение вы "гарантируете" на месте.

Если вам нужна гибкость в ваших возвращаемых данных (т.е.добавление / удаление полей и т.д.) вы можете выполнить одно из следующих действий:

1. Обновите свои определения WSDL и опубликуйте службы, которые могут перенаправлять старые версии на более новые
2. Используйте более абстрактные типы возвращаемых данных, такие как XML, чтобы скрыть сложность или изменяющиеся данные.

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

Answer 2

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

То, что мы сделали, было действительно просто;в день выпуска нового API мы бы создали структуру папок следующим образом:

http://mydomain.com/path/to/service/2009/12/17/servicename.svc

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

http://mydomain.com/path/to/service/2009-12-17/servicename.svc

Answer 3

WSDL фактически является вашим опубликованным SOAP-интерфейсом вашего веб-сервиса.Многие клиенты используют это для создания своих клиентских прокси, которые предоставляют все ваши методы веб-сервиса на выбранном ими языке программирования.Большинство из этих сгенерированных кодом клиентов очень хрупкие и предпочтут выдавать исключение, если они видят элемент, который они не распознают (т.е.его нет в WSDL), а не игнорировать это.Некоторые из них более расслаблены, и это действительно зависит от клиентской технологии, которую они используют, т. е.Новые DataContract от Microsoft имеют интерфейс IExtensibleData на своих клиентах для специального хранения данных, которые они не распознают, поэтому они в основном игнорируют неизвестные элементы.

Клиентские прокси-серверы SOAP и code-generated легко справляются с такого рода проблемами, потому что они генерируют клиентов, которые хотят понимать "всю схему", а не только те биты, которые их интересуют.Альтернативой для них является использование анализатора Xml и просто извлечение необходимых им битов.

Если ваш веб-сервис находится в стадии разработки или постоянно меняется, то SOAP - действительно не лучший выбор для вас, поскольку это будет означать, что при каждом изменении им придется заново создавать, перестраивать и повторно развертывать своих клиентов-служб.В зависимости от вашей ситуации вы можете рассмотреть возможность предоставления вместо этого веб-сервисов REST + POX (обычный старый Xml), поскольку их проще анализировать, поскольку они не имеют накладных расходов SOAP, могут вызываться через обычный URL и использоваться средами, в которых нет библиотеки SoapClient (напримернепосредственно в браузере, используя AJAX)

Answer 4

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