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

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

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

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

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

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

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

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

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

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

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