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

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

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

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

ОТВЕТЫ

Ответ 1

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

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

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

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

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

Ответ 2

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

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

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

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

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

Ответ 3

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

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

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

Ответ 4

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