Назад совместимость и веб-сервисы
Таким образом, я немного плохо знаком с веб-сервисами, и ситуация недавно подошла, где мы добавили элемент к типу данных, который возвращается клиенту. Клиенты жаловались, что это повредило их реализацию, потому что она дросселировала на новом элементе, который она не ожидала. (мы предоставляем услуги через Axis2).
Мне это походит на безопасное изменение, которое клиент должен смочь обработать корректно (я работал с некоторыми платформами невеб-сервиса, где добавление дополнительной информации было абсолютно приемлемо). Я мог понять, удалили ли мы или переименовали некоторые поля это, которое вызвало бы проблемы для клиента.
В основном я ожидал бы, что wsdl будет действовать как интерфейс. Если мы вносим изменение, которое по существу выделяет подтипы в том интерфейсе, я ожидал бы, что клиент счастливо проигнорирует посторонние элементы. Это - просто короткое выйти из веб-сервисов, или существует ли нормальный способ внести пассивные изменения в сервисы так, чтобы новые клиенты могли получить дополнительные данные, в то время как старые клиенты могут обновить на их досуге?
3 ответа
WSDL фактически действует как контракт, а не как интерфейс. WSDL точно описывает, что операция ожидает «получить» и что она ожидает «вернуть». Самая близкая аналогия с этим - в C изменение прототипа функции без изменения самой функции, они не будут совпадать, и это вызовет проблемы.
Чем более конкретен WSDL, тем большее поведение вы «гарантируете», чтобы быть на месте .
Если вам нужна гибкость в возвращаемых данных (например, добавление / удаление полей и т. Д.), Вы можете выполнить одно из следующих действий:
- Версия ваших определений WSDL и опубликовать службы, которые могут перенаправлять старые версии на новые версии
- Использовать более абстрактные типы возвращаемых данных, такие как 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 (Plain Old Xml) вместо этого, поскольку их проще анализировать, поскольку они не имеют накладных расходов на SOAP, могут вызываться через обычный URL-адрес и использоваться средами, которые нет библиотеки SOAPClient (например, прямо в браузере с использованием AJAX)