Commentaires sur : Versioning de services REST http://blog.octo.com/versioning-de-services-rest/ Le blog d'OCTO Technology, cabinet d'architectes en systèmes d'information Fri, 05 Mar 2010 17:21:23 +0000 http://wordpress.org/?v=2.9.2 hourly 1 Par : OCTO talks ! » Des alternatives aux bases de données relationnelles… http://blog.octo.com/versioning-de-services-rest/comment-page-1/#comment-1781 OCTO talks ! » Des alternatives aux bases de données relationnelles… Wed, 11 Nov 2009 07:26:17 +0000 http://blog.octo.com/?p=2838#comment-1781 [...] possibilités de versionning plus simple puisque la signature sera [...] [...] possibilités de versionning plus simple puisque la signature sera [...]

]]> Par : Georges Abidbol http://blog.octo.com/versioning-de-services-rest/comment-page-1/#comment-1294 Georges Abidbol Mon, 18 May 2009 17:34:44 +0000 http://blog.octo.com/?p=2838#comment-1294 A première vue, je ne suis pas vraiment fan d'un module web "routeur". Je ne pense pas que ce soit de la responsabilité d'un serveur d'applications que de router une requête cliente vers une application web. A moins évidemment que ce choix soit justifié. C'est à dire par exemple si la décision de routage est basée sur des règles complexes nécessitant un traitement ou l'accès à des ressources ou des services particuliers... Dans le cas cité par Dominique (déploiement de 2 applis web pour 2 versions différentes), la décision de routage s'effectue à partir de l'analyse d'entêtes HTTP. Certes, c'est au niveau applicatif que cela se passe, mais notre pauvre serveur d'applications a sans doute autre chose à faire que de s'occuper de ça. Je refilerai plutôt le boulot à un reverse proxy, qui peut de façon plus efficace décider de router les requêtes vers la bonne version déployée sur notre besogneux serveur d'application, délestant ainsi ce dernier. C'est un avis tout à fait personnel :) C'est un choix qui dépend largement du domaine fonctionnel : fréquences d'apparition de nouvelles fonctions et/ou d'évolutions, etc... Quoiqu'il en soit, il arrive un moment où la mise à disposition et le maintien de trop de versions d'un même service devient trop complexe. D'où la nécessité sans doute de marquer certains services comme "dépréciés", comme une manière de prévenir les clients que le service est amené à ne plus être supporté, et ainsi à les amener à upgrader vers une version plus récente du client rest. Le sujet est vaste... A première vue, je ne suis pas vraiment fan d’un module web « routeur ».
Je ne pense pas que ce soit de la responsabilité d’un serveur d’applications que de router une requête cliente vers une application web. A moins évidemment que ce choix soit justifié. C’est à dire par exemple si la décision de routage est basée sur des règles complexes nécessitant un traitement ou l’accès à des ressources ou des services particuliers…
Dans le cas cité par Dominique (déploiement de 2 applis web pour 2 versions différentes), la décision de routage s’effectue à partir de l’analyse d’entêtes HTTP. Certes, c’est au niveau applicatif que cela se passe, mais notre pauvre serveur d’applications a sans doute autre chose à faire que de s’occuper de ça.
Je refilerai plutôt le boulot à un reverse proxy, qui peut de façon plus efficace décider de router les requêtes vers la bonne version déployée sur notre besogneux serveur d’application, délestant ainsi ce dernier.

C’est un avis tout à fait personnel :)

C’est un choix qui dépend largement du domaine fonctionnel : fréquences d’apparition de nouvelles fonctions et/ou d’évolutions, etc… Quoiqu’il en soit, il arrive un moment où la mise à disposition et le maintien de trop de versions d’un même service devient trop complexe. D’où la nécessité sans doute de marquer certains services comme « dépréciés », comme une manière de prévenir les clients que le service est amené à ne plus être supporté, et ainsi à les amener à upgrader vers une version plus récente du client rest.

Le sujet est vaste…

]]> Par : Dominique Jocal http://blog.octo.com/versioning-de-services-rest/comment-page-1/#comment-1291 Dominique Jocal Fri, 15 May 2009 12:41:27 +0000 http://blog.octo.com/?p=2838#comment-1291 C'est l'autre sujet, très connexe certes, du multiversion côté implem; j'ai des exemples soap ou rpc propriétaire à vous soumettre, peut être sont ils valides pour rest également? (hypothèse peut être fragile) Première approche effectivement : même webapp; vu dans un système de réservation transport : 1 seul code qui supporte d'être interrogé de 2 façons différentes, avec des bon vieux If organisés aux bon endroits (= pas trop!), et pleins de tests de non régression. En l'occurrence, le système offrait des fonctionnalités récentes aux clients de l'ancienne API (ça ne changeait pas les apis des request ni des responses), donc le partage de code entre les 2 versions était nécessaire, et il avait été jugé plus facile de faire la maintenance sur un code unique. Pas vu mais envisageable en théorie : déployer 2+1 webapp sur le cluster, la 3ième minuscule webapp contenant le code de routage côté serveur selon la version; pour le monde java, appeler le dispatcher fourni par le servlet context (me semble t il), en tout cas celui qui est global, qui permet de basculer vers n'importe quel autre contexte url du serveur d'app, sans revenir vers le client. Enfin, il y a effectivement l'approche de transformation de message par un intermédiaire type ESB; les grands fournisseurs de réservation fonctionnent beaucoup comme ça (encore une fois, en approche message proche rpc, mais j'ai l'impression que le sujet du multiversion côté implem est orthogonal, non ?) C’est l’autre sujet, très connexe certes, du multiversion côté implem; j’ai des exemples soap ou rpc propriétaire à vous soumettre, peut être sont ils valides pour rest également? (hypothèse peut être fragile)

Première approche effectivement : même webapp; vu dans un système de réservation transport : 1 seul code qui supporte d’être interrogé de 2 façons différentes, avec des bon vieux If organisés aux bon endroits (= pas trop!), et pleins de tests de non régression.

En l’occurrence, le système offrait des fonctionnalités récentes aux clients de l’ancienne API (ça ne changeait pas les apis des request ni des responses), donc le partage de code entre les 2 versions était nécessaire, et il avait été jugé plus facile de faire la maintenance sur un code unique.

Pas vu mais envisageable en théorie : déployer 2+1 webapp sur le cluster, la 3ième minuscule webapp contenant le code de routage côté serveur selon la version; pour le monde java, appeler le dispatcher fourni par le servlet context (me semble t il), en tout cas celui qui est global, qui permet de basculer vers n’importe quel autre contexte url du serveur d’app, sans revenir vers le client.

Enfin, il y a effectivement l’approche de transformation de message par un intermédiaire type ESB; les grands fournisseurs de réservation fonctionnent beaucoup comme ça (encore une fois, en approche message proche rpc, mais j’ai l’impression que le sujet du multiversion côté implem est orthogonal, non ?)

]]> Par : Gilles S http://blog.octo.com/versioning-de-services-rest/comment-page-1/#comment-1290 Gilles S Fri, 15 May 2009 07:57:20 +0000 http://blog.octo.com/?p=2838#comment-1290 Merci pour ces posts, peut on pousser la reflexion plus loin? Pouvez vous également expliquer comment vous faites vivre les 2 versions de service coté serveur ? Est-ce qu'elles sont cote à cote dans la meme webapp ? Est-ce qu'on fait une 2e webapp? Est-ce qu'on sort la machine de guerre avec un bus qui transforme le format V1 en V2 ? Pouvez vous svp faire part de vrais retours d'experience pour certains cas? Merci encore Gilles S Merci pour ces posts, peut on pousser la reflexion plus loin? Pouvez vous également expliquer comment vous faites vivre les 2 versions de service coté serveur ?
Est-ce qu’elles sont cote à cote dans la meme webapp ? Est-ce qu’on fait une 2e webapp? Est-ce qu’on sort la machine de guerre avec un bus qui transforme le format V1 en V2 ?
Pouvez vous svp faire part de vrais retours d’experience pour certains cas?

Merci encore
Gilles S

]]> Par : Benoit Guillou http://blog.octo.com/versioning-de-services-rest/comment-page-1/#comment-1284 Benoit Guillou Wed, 13 May 2009 12:18:41 +0000 http://blog.octo.com/?p=2838#comment-1284 Quelle classe Georges ! Le User Agent est en effet un autre moyen de préciser la version du service à attaquer sans triturer l'URL de la ressource. Le champs Accept reste dans l'absolu l'attribut d'entête HTTP à privilégier. Pour ce qui est de ta remarque Gabriel 'intestable par le navigateur', ce n'est pas structurant dans la manière de penser les services REST. La testabilité du navigateur n'est pas la killer feature de REST (surtout si tu ne testes que les GET). De plus avec un petit about:config tu peux tout à fait modifier ce champs ACCEPT. A noter que le plugin Poster de Firefox permet d'envoyer n'importe quel type de requête et donc indispensable si tu souhaites tester un service à partir de ton navigateur. La solution "http://…/albumsAndArtists/12133" retombe dans les travers d'un v2 dans l'url. De plus, tu changes ici complètement ton contrat de service : la ressource album n'existe plus et tu crées une nouvelle ressource albumsAndArtists. Quelle classe Georges !
Le User Agent est en effet un autre moyen de préciser la version du service à attaquer sans triturer l’URL de la ressource. Le champs Accept reste dans l’absolu l’attribut d’entête HTTP à privilégier.

Pour ce qui est de ta remarque Gabriel ‘intestable par le navigateur’, ce n’est pas structurant dans la manière de penser les services REST. La testabilité du navigateur n’est pas la killer feature de REST (surtout si tu ne testes que les GET). De plus avec un petit about:config tu peux tout à fait modifier ce champs ACCEPT. A noter que le plugin Poster de Firefox permet d’envoyer n’importe quel type de requête et donc indispensable si tu souhaites tester un service à partir de ton navigateur.

La solution « http://…/albumsAndArtists/12133″ retombe dans les travers d’un v2 dans l’url. De plus, tu changes ici complètement ton contrat de service : la ressource album n’existe plus et tu crées une nouvelle ressource albumsAndArtists.

]]> Par : Georges Abidbol http://blog.octo.com/versioning-de-services-rest/comment-page-1/#comment-1283 Georges Abidbol Wed, 13 May 2009 07:58:06 +0000 http://blog.octo.com/?p=2838#comment-1283 Article intéressant. La remarque de Gabriel est pertinente également. C'est pourquoi il est envisageable d'identifier la représentation à envoyer au client via le User-Agent qu'il envoie. Un proxy "un peu fasciste" :-) laissera sans doute mieux passer un User-Agent, plus sensible au changement, qu'un en-tête peu commun. ex : GET http://.../albums/12133 User-Agent: client-v1 => Retourne la représentation v1 GET http://.../albums/12133 User-Agent: client-v2 => Retourne la représentation v2 Ainsi, c'est toujours le client qui est porteur de la version de contenu avec laquelle il est compatible. La montée de version nécessite néanmoins une modification du paramètre user-agent du client http utilisé (tout comme pour la solution avec négociation de contenu cela dit). Article intéressant. La remarque de Gabriel est pertinente également. C’est pourquoi il est envisageable d’identifier la représentation à envoyer au client via le User-Agent qu’il envoie. Un proxy « un peu fasciste » :-) laissera sans doute mieux passer un User-Agent, plus sensible au changement, qu’un en-tête peu commun.
ex :
GET http://…/albums/12133
User-Agent: client-v1
=> Retourne la représentation v1

GET http://…/albums/12133
User-Agent: client-v2
=> Retourne la représentation v2

Ainsi, c’est toujours le client qui est porteur de la version de contenu avec laquelle il est compatible. La montée de version nécessite néanmoins une modification du paramètre user-agent du client http utilisé (tout comme pour la solution avec négociation de contenu cela dit).

]]> Par : Gabriel Guillon http://blog.octo.com/versioning-de-services-rest/comment-page-1/#comment-1281 Gabriel Guillon Tue, 12 May 2009 13:09:32 +0000 http://blog.octo.com/?p=2838#comment-1281 Un peu de discussion... - la chaîne de caractère dans ton en-tête peut ne passer passer un proxy un peu fasciste, - c'est intestable automatiquement par un navigateur, Et qui dit changement de version dit un peu de boulot côté consommateur de ton webservice. Dans ce cas, pourquoi ne pas carrément changer le nom du WS? Si on reprend ton exemple: GET http://.../albums/12133 Pour la v1 Et pour la v2: GET http://.../albumsAndArtists/12133 Un peu de discussion…
- la chaîne de caractère dans ton en-tête peut ne passer passer un proxy un peu fasciste,
- c’est intestable automatiquement par un navigateur,
Et qui dit changement de version dit un peu de boulot côté consommateur de ton webservice.
Dans ce cas, pourquoi ne pas carrément changer le nom du WS?
Si on reprend ton exemple:
GET http://…/albums/12133
Pour la v1
Et pour la v2:
GET http://…/albumsAndArtists/12133

]]> Par : Bla http://blog.octo.com/versioning-de-services-rest/comment-page-1/#comment-1280 Bla Tue, 12 May 2009 07:37:29 +0000 http://blog.octo.com/?p=2838#comment-1280 Merci pour l'article, tres clair. Y'a-t-il des desavantages ou des limitations avec ce "Versonning par Accept" ? Merci pour l’article, tres clair.

Y’a-t-il des desavantages ou des limitations avec ce « Versonning par Accept » ?

]]>