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

Question

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

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

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

Answer 1

WSDL фактически действует как контракт, а не как интерфейс. WSDL точно описывает, что операция ожидает «получить» и что она ожидает «вернуть». Самая близкая аналогия с этим была бы в C, изменяющем прототип для функции без изменения самой функции, они не будут совпадать, и это вызывает проблемы.

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

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

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

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

Answer 2

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

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

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

Answer 3

В прошлом, когда я имел дело с открытыми 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

Answer 4

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