Stratégies de mise à jour ou de gestion de versions de services web?
Je suis intéressé d'entendre les meilleures pratiques sur la façon dont les différentes versions de services web sont gérées.
Pour clarifier, si vous avez des méthodes web exposées en tant que service web, alors vous voulez ajouter une fonctionnalité/fonctionnalité et ainsi changer la signature de ces appels de méthode, comment gérez-vous cela d'une manière qui ne casse pas tous vos clients qui appellent actuellement le service?
Déployez-vous le service sur une URL différente?
Mettez-vous une version dans le nom de la méthode lui-même (MyMethod, mymethodv2 etc. - pouah..)
Transmettez-vous une version dans le cadre de l'appel de méthode avec une liste de paramètres?
Est-ce que Quelqu'un sait comment Google ou Amazon gérer ce scénario avec leur vaste bibliothèque de services Web?
EDIT: Jusqu'à présent, j'ai trouvé de bonnes informations dans cet article d'Oracle . Aussi cette entrée de blog sur certaines spécificités Java était utile. Je suis toujours curieux de voir les autres approches.
5 réponses
La manière typique de versionner un service web consiste à demander aux clients de spécifier la version souhaitée. Vous pouvez autoriser des contraintes simples, comme ">2.0", "
Les Techniques pour fournir la version varient. Certains préconisent l'utilisation de L'URL, d'autres encouragent les en-têtes, certains peuvent l'inclure comme paramètre de l'appel d'api. Presque cependant, aucun ne changerait le nom de la méthode. C'est équivalent au versioning" package "ou" namespace " dont parle le lien OSGi. Cela rendra la mise à niveau très difficile et empêchera les gens de mettre à niveau plus que tout changement au service réel.
Cela dépend aussi de la façon dont vous accédez à vos services web. Si vous utilisez REST, alors garder l'URL propre et utiliser des en-têtes est le plus logique (et il serait trivial de le pirater en tant que paramètre de requête, si nécessaire). Si vous êtes en utilisant SOAP / XMLRPC / whatever-RPC, puis le mettre dans L'URL est généralement bien.
Edit 5/2011 FWIW, bien que je ne sois pas d'accord, le blog D'Apigee recommande de mettre la version dans L'URL .
Comment le client spécifie la version est généralement assez facile. Ce qui est plus compliqué, c'est comment vous exécutez toutes les versions simultanément. La plupart des langues n'ont pas de moyen de charger plusieurs versions de la même bibliothèque / module / Classe/fonction dans le même environnement d'exécution (be c'est une machine virtuelle, un processus ou ce que vous avez). Le lien OSGi que vous avez fourni est la solution de Java pour permettre cela.
En pratique, OSGi sera exagéré pour la plupart des situations. Il est généralement plus facile de proxy les demandes obsolètes à un autre serveur ou processus.
La meilleure façon de "version" de vos services, cependant, est de construire l'extensibilité et la flexibilité en eux afin qu'ils restent avant et arrière compatibles. Cela ne signifie pas que toutes les versions doivent être compatibles les unes avec les autres, mais consécutives les versions doivent être compatibles les unes avec les autres.
Je peux vous dire que la solution de création de doAPIFunction, doAPIFunctionV2 et doAPIFunctionV3, etc n'a produit que des maux de tête à l'endroit où je travaille. Ajoutez à cela le manque de noms de fonction clairement descriptifs signifie toutes sortes de folie.
Vous voulez effacer les noms de fonctions API, et si une api change, le but serait d'essayer de le faire de la manière la plus rétrocompatible possible. Je suggère de versionner vos points d'entrée afin que chaque point d'entrée supporte une API stable et doFunction dans example.org/api-1.0 / peut être différent de example.org/api-2.0 s'il y avait une bonne raison de changer la sémantique.
Je ne suis pas sûr d'avoir bien compris votre question. Mais mes 2 cents. Si la signature de la méthode change comme un autre nouveau paramètre, pourquoi ne peut-elle pas être rendue facultative? Mais si un type de données de paramètre existant est modifié, il n'est pas applicable.
Votez ceci si c'est faux. :)
C'était plus simple quand vous pouviez avoir le même nom de méthode webservice, et des paramètres différents, il y a des années. :)
Une fois que vous écrivez un webservice, vous établissez un contrat avec les clients que c'est ce que vous soutiendrez.
Pour les anciennes méthodes, je suggère de me connecter pour voir si elles sont utilisées, et par qui, pour voir si vous pouvez les mettre à jour.
Autre que cela, le mieux est d'écrire simplement une nouvelle méthode, de sorte que vous pouvez avoir plusieurs noms de fonctions similaires diffèrent par une version.
Le problème avec le passage d'un numéro de version est que vous devez vous assurer que les clients passent toujours un numéro valide, ce qui, si vous générez les stubs, fonctionnera, mais si vous ne le faites pas, c'est très fragile.
Mettre un numéro de version dans le nom semble mieux fonctionner pour moi, car cela rend évident ce qui est vieux, et vous pouvez utiliser AOP pour enregistrer plus facilement les anciennes versions des méthodes webservice.
Une façon d'atténuer cela est de coder par contrat et en définissant des interfaces dans la pierre. Vous ne pouvez jamais vraiment changer les signatures de fonction , Vous pouvez cependant les surcharger. Envisager l' .NET DE L'API. Il déprécier certaines méthodes, mais ils continuent à travailler parce que les programmes codés autour d'eux peuvent casser. Une nouvelle version du service peut être exposée à un URI différent (v2.webservice.com) pour lui donner une nouvelle feuille de route et v1 devrait continuer à être soutenu.