Стратегии обновления или управления версиями веб-сервисов?

Мне интересно узнать, как лучше обрабатывать различные версии веб-сервисов.

Чтобы прояснить, если у вас есть некоторые веб-методы, представленные как веб-служба, то вы хотите добавить функцию/функциональность и, таким образом, изменить подпись этих вызовов методов, как вы справляетесь с этим так, t разорвать всех ваших клиентов, которые в настоящее время звонят в службу?

Развертываете ли вы службу по другому URL?

Вы помещаете версию в имя самого метода (MyMethod, MyMethodv2 и т.д. - ugh..)

Вы передаете версию как часть вызова метода вместе со списком параметров?

Кто-нибудь знает, как Google или Amazon справляются с этим сценарием с помощью обширной библиотеки веб-сервисов?

EDIT: До сих пор я нашел хорошую информацию в этой статье из Oracle. Также эта запись в блоге о некоторых особенностях Java была полезна. Мне все еще любопытно видеть некоторые из других подходов.

Ответ 1

Типичным способом управления версиями веб-службы является указание клиентам желаемой версии. Вы можете разрешить для простых ограничений, таких как " > 2.0", "< 1,5" или "= 1,1". Естественно, вы хотите свести к минимуму количество поддерживаемых версий для вашего собственного здравомыслия. Если клиент не указывает версию, вы принимаете последнюю.

Способы предоставления версии различаются. Некоторые защитники используют URL-адрес, другие - заголовки, некоторые могут включать его в качестве параметра вызова api. Тем не менее, почти никто не изменит имя метода. То, что эквивалентно версии "пакет" или "пространство имен", о которой говорит ссылка OSGi. Это очень затруднит модернизацию и помешает людям модернизировать больше, чем любые изменения в фактическом сервисе.

Это также зависит от того, как вы получаете доступ к своим веб-сервисам. Если вы используете REST, то сохранение URL-адреса в чистом виде и использование заголовков имеет наибольший смысл (и было бы тривиально взломать его в качестве параметра запроса, если потребуется). Если вы используете SOAP/XMLRPC/whatever-RPC, тогда его размещение в URL-адресе обычно прекрасное.

Изменить 5/2011 FWIW, хотя я не согласен, Блог Apigee рекомендует поместить версию в URL.

Как клиент указывает версию, обычно довольно легко. Более сложным является то, как вы запускаете все версии одновременно. Большинство языков не имеют возможности загружать несколько версий одной и той же библиотеки/модуля/класса/функции в одну среду выполнения (будь то виртуальная машина, процесс или что у вас есть). Ссылка OSGi, которую вы предоставили, - это решение Java, разрешающее это.

На практике OSGi будет чрезмерным для большинства ситуаций. Его обычно проще проксировать устаревшие запросы на другой сервер или процесс.

Лучший способ "версии" ваших услуг состоит в том, чтобы создать в них расширяемость и гибкость, чтобы они оставались совместимыми вперёд и назад. Это не означает, что все версии должны быть совместимы друг с другом, но последовательные версии должны быть совместимы друг с другом.

Ответ 2

Я могу сказать вам, что решение создания doAPIFunction, doAPIFunctionV2 и doAPIFunctionV3 и т.д. не создало ничего, кроме головных болей в том месте, где я работаю. Добавьте к этому, что отсутствие четко описательных имен функций означает все виды безумия.

Вам нужны четкие имена функций API, и если api меняется, цель будет заключаться в том, чтобы попытаться сделать это как способ обратной совместимости, насколько это возможно. Я хотел бы предложить управлять версиями своих точек входа, чтобы каждая точка входа поддерживала стабильный API и doFunction в example.org/api-1.0/может отличаться от example.org/api-2.0, если есть веские причины для изменения семантики.

Ответ 3

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

Проголосуйте, если это неправильно.:)

Ответ 4

Это было проще, когда вы могли иметь одно и то же имя метода webservice и разные параметры, много лет назад.:)

Как только вы напишете webservice, вы заключаете контракт с клиентами, что это то, что вы будете поддерживать.

Для более старых методов я предлагаю вести журнал, чтобы узнать, используются ли они и кем, чтобы узнать, можете ли вы их обновить.

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

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

Помещение номера версии в названии, по-видимому, наилучшим образом подходит для меня, так как это делает очевидным то, что является старым, и вы можете использовать AOP для более легкого регистрации более старых версий методов webservice.

Ответ 5

Одним из способов смягчения этого является кодирование по контракту и установление границ интерфейса. Вы никогда не сможете изменять сигнатуры функций, однако вы можете перегрузить их. Рассмотрим .NET API. Он осуждает некоторые методы, но они продолжают работать, потому что программы, закодированные вокруг них, могут сломаться. Новая версия службы может быть выставлена на другом URI (v2.webservice.com), чтобы дать ей свежую дорожную карту, и v1 необходимо будет продолжать поддерживать.