Стратегии веб-сервисов обновления или управления версиями?
Если вы используете Godaddy (или любой другой общий хостинг в этом отношении), они могут ограничивать исходящие соединения только для портов 80 и 443.
5 ответов
Типичный способ управления версиями веб-службы состоит в том, чтобы клиенты указывали желаемую версию. Вы можете учесть простые ограничения, такие как «> 2.0», «<1.5» или «= 1.1». Естественно, вы хотите минимизировать количество поддерживаемых версий для вашего собственного здравомыслия. Если клиент не указывает версию, вы принимаете последнюю версию.
Способы предоставления версии различаются. Некоторые выступают за использование URL-адреса, другие поощряют использование заголовков, некоторые могут включать его в качестве параметра вызова API. Однако почти никто не изменил бы название метода. Это эквивалентно "пакету" или "пространству имен", о котором говорится в ссылке OSGi. Это сделает обновление очень сложным и помешает людям выполнить обновление больше, чем любые изменения в фактическом сервисе.
Это также зависит от того, как вы получаете доступ к своим веб-службам. Если вы используете REST, то сохранение URL-адреса в чистоте и использование заголовков имеет наибольший смысл (и было бы тривиально взломать его в качестве параметра запроса, если это необходимо). Если вы используете SOAP / XMLRPC / something-RPC, то размещение его в URL-адресе обычно нормально.
Редактировать 5/2011 FWIW, хотя я не согласен, блог Apigee рекомендует поместить версию в URL .
Как клиент указывает версию, обычно довольно просто. Что еще сложнее, так это то, как вы запускаете все версии одновременно. Большинство языков не имеют возможности загружать несколько версий одной и той же библиотеки / модуля / класса / функции в одну среду выполнения (будь то виртуальная машина, процесс или что-то еще). Ссылка OSGi, которую вы предоставили, - это решение Java, позволяющее это сделать.
На практике OSGi будет излишним для большинства ситуаций. Обычно проще проксировать устаревшие запросы на другой сервер или процесс.
Однако лучший способ «версировать» ваши сервисы - это встроить в них расширяемость и гибкость, чтобы они оставались прямой и обратной совместимостью. Это не означает, что все версии должны быть совместимы друг с другом, но последовательные версии должны быть совместимы друг с другом.
Я могу сказать вам, что решение по созданию doAPIFunction, doAPIFunctionV2, doAPIFunctionV3 и т.д. не принесло ничего, кроме головной боли в том месте, где я работаю. Добавьте к этому отсутствие четко описательных имен функций, что означает всякое безумие.
Вам нужны четкие имена функций API, и если api изменяется, цель будет заключаться в том, чтобы попытаться сделать это как можно более обратно совместимым способом. Я бы предложил использовать версии ваших точек входа, чтобы каждая точка входа поддерживала стабильный API, и функция doFunction в example.org/api-1.0/ могла отличаться от example.org/api-2.0, если была веская причина для изменения семантики.
Раньше было проще, когда вы могли иметь одно и то же имя метода веб-службы и разные параметры, много лет назад. :)
После того, как вы напишете веб-сервис, вы заключаете контракт с клиентами, что это то, что вы будете поддерживать.
Для более старых методов я бы предложил вести журнал, чтобы увидеть, используются ли они и кем, чтобы посмотрим, сможете ли вы заставить их обновить.
В остальном лучше всего просто написать новый метод, чтобы у вас могло быть несколько похожих имен функций, которые различаются в зависимости от версии.
Проблема с передачей версии Номер состоит в том, что вы должны гарантировать, что клиенты всегда передают действительный номер, который, если вы создадите заглушки, будет работать, но если вы этого не сделаете, это очень хрупко.
Ввод номера версии в имя кажется лучше всего работает для меня, так как это показывает, что старое,
Я не уверен, правильно ли я понял ваш вопрос. Но мои 2 цента. Если сигнатура метода изменяется, как новый параметр, почему ее нельзя сделать необязательной? Но если существующий тип данных параметра изменен, то это не применимо.
Проголосуйте за это, если это явно неверно. :)
Одним из способов смягчения этого является кодирование по контракту и установка интерфейсов в камне. Вы никогда не сможете реально изменить сигнатуры функций, однако вы можете их перегрузить. Рассмотрим .NET API. Некоторые методы не рекомендуются, но они продолжают работать, потому что программы, написанные вокруг них, могут сломаться. Новая версия службы может быть представлена по другому URI (v2.webservice.com), чтобы дать ей новую дорожную карту, и v1 необходимо будет продолжать поддерживать.