Discussion :

[Air P-E]

Bonjour à tous,

J'ai actuellement un projet qui utilise Web API pour fournir des services. J'aimerais la modifier pour gérer le versioning. J'ai donc épluché mon meilleur ami Google et je tombe sur plusieurs blogs qui traitent ce point mais j'ai du mal à faire un choix. De ce que j'ai pu voir, il y a 3 solutions, définir la version dans :
- le header (champ custom ou non ?)
- une partie de l'url (par exemple : /api/v1/Book/GetAll
- query parameter (par exemple /api/Book/GetAll?v=1)

Je trouve la dernière solution "dégueulasse" pour pas mâcher mes mots car visuellement c'est moche, de plus ça signifie qu'il faut que je rajoute l'élément "v" à chacune de mes méthodes déjà existante, donc modifier tout et renseigner ce champ à chaque fois.
J'ai tendance à choisir dans le header car je trouve ça propre et ça ne casse pas les URLs (existantes ou futures).
Mais je trouve que la solution dans l'url est pas mal pour tester les services rapidement dans le navigateur.

Quelle solution choisir et pourquoi ?

Merci par avance.

[chamamo]

Je me posais la question il y a un petit moment, je confirme que la dernière proposition est dégueulasse, le versionning dans l'URL semble être la meilleurs solution, mais je ne l'ai pas mis en place car tu as un service par version, dans le cas ou tu as par exemple 10 service avec 3 version, tu auras en réalité 30 classes à gérer, ça reste du code dupliqué.

J'ai opté pour une versionning global de l'application serveur et de l'application cliente.

- Le client envoie sa requête HTTP avec sa version dans le header.
- Le serveur reçoit la requête et vérifie si la version du client est compatible (le serveur à une version minimale du client à supporter)
- Si la version du client est inférieure à la version minimale supportée le serveur envoie une exception pour lui dire qu'il faut mettre à jour l'application cliente.

Maintenant le test dans l'autre sens, le client à une version minimale supportée du serveur
- dans la même requête le client envoie dans le header la version minimale supportée du serveur
- le serveur vérifie la version reçue du client avec sa version courante, si ça ne correspond pas une exception est envoyée au client, cette fois-ci pour dire que la version du client est supérieure à la version du serveur, il faut mettre à jour le serveur.

J'espère que cette approche pourrait correspondre à ce que tu cherches.

[Air P-E]

Bonjour chamamo,

On se croise une fois de plus.

J'ai continué à me renseigner (quand je pouvais) et j'ai trouvé d'autres infos ou arguments qui me font douter pour la version avec la version dans l'url.

Effectivement j'avais déjà dans l'idée que j'aurai du code dupliqué. Je trouve ça normal dans le sens où si un service est bogué, tu es bien obligé d'avoir une nouvelle version donc un code différent (tout en gardant l'ancienne pour les clients l'utilisant encore). Au final, le code n'est pas forcément dupliqué, si différent, puis une version une fois finalisée tu ne la touches plus. donc toujours qu'une seule version à gérer.

Actuellement, nous avons une "gestion" (si on peut appeler ça comme ça) où on déploie toute la partie serveur avec l'API et les Front Office mais ça signifie créer de nouveaux noms de domaines avec des ports différents etc. enfin c'est complètement moche comme solution, nous sommes mal parti.

Pour le principe de tout relivrer à chaque fois, comment gères-tu les différentes version du serveur ? Tu as donc comme nous plusieurs instances à gérer. Nous n'en avons que 2 pour le moment et ça devient déjà ingérable...

D'après ces liens :
- http://barelyenough.org/blog/2008/05...-web-services/ et
- http://www.mnot.net/blog/2011/10/25/...ning_smackdown

la solution de la version dans l'url n'est peut-être pas la mieux. Qu'en penses-tu ?

[chamamo]

Oui encore une fois, le monde est petit, et ce forum l'est encore moins

Tu veux dire quoi par plusieurs instances et plusieurs domaines? tu gardes l'ancienne version quand tu déploies la nouvelle?

Moi j'ai une seule instance (enfin une seule version) que je met à jour si besoin, et comme j'ai expliqué précédemment si j'ai des changements qui nécessitent une version récente de l'application cliente je lance une exception au client pour lui demander de mettre à jour sa version, ça me semblait moins lourd que gérer plusieurs versions d'un même services, sachant que j'en ai environ 30 services pour l'instant.

[Air P-E]

Oui exactement, je garde l'ancienne version sur demande du client. Et sur le moment c'est la seule solution qui a été trouvée. C'est pourquoi, nous ne pouvons pas rester dans cette situation.

Au début nous faisions comme toi à remplacer la version par la dernière, mais aujourd'hui il faut gérer la population cliente sur les différentes versions.

Je suis d'accord avec l'idée de renvoyer une exception sur une version trop ancienne mais en l’occurrence pour nous, nous n'avons actuellement que deux versions... C'est dommage !

Je pense partir sur une solution avec la version dans l'url, mais je suis pas encore décidé. J'ai pas eu le temps de me repencher sur la question depuis.

J'aimerais avoir d'autres avis, des retours d'expérience mais ça semble vide par ici...
C'est fini les vacances, revenez !

[Air P-E]

Je reviens sur le sujet.

Alors aujourd'hui j'ai pu avancé. J'ai réalisé un POC où je fais appel à une version de ma web api suivant la version dans le header.
J'aimerais savoir comment je peux gérer le cas de l'avertissement dans le retour d'une requête qu'il faut utiliser une version minimale de l'API (que la version que l'utilisateur utilise actuellement est obsolète et/ou plus supportée et sera supprimée) ?

Normalement une vielle API versionnée n'est plus censée être modifiée, du coup comment renvoyer dans la requête qu'il faut faire un upgrade sans avoir à modifier le code ?