Commentaires sur : Versioning de services REST http://blog.octo.com/versioning-de-services-rest/?utm_source=rss&utm_medium=rss&utm_campaign=versioning-de-services-rest Le blog d'OCTO Technology, cabinet d'architectes en systèmes d'information Wed, 08 Feb 2012 14:30:47 +0000 hourly 1 http://wordpress.org/?v=3.3.1 Par : JY Cr http://blog.octo.com/versioning-de-services-rest/comment-page-1/#comment-4370 JY Cr Fri, 15 Jul 2011 22:40:21 +0000 http://blog.octo.com/?p=2838#comment-4370 Pour continuer la discussion, ils en parlent ici aussi : http://www.la-grange.net/2011/07/14/api-version Pour continuer la discussion, ils en parlent ici aussi : http://www.la-grange.net/2011/07/14/api-version

]]> Par : Lecture de la semaine « Un expresso sans sucre http://blog.octo.com/versioning-de-services-rest/comment-page-1/#comment-4189 Lecture de la semaine « Un expresso sans sucre Sun, 15 May 2011 19:09:49 +0000 http://blog.octo.com/?p=2838#comment-4189 [...] Versioning des Services REST. Sur le Blog Octo, Benjamin Magan nous propose une stratégie pour le versioning des Services REST. La technique proposée est élégante et repose sur la négociation du contenu et l’entête « Content-Type ». Le client indique à l’aide cet entête, non seulement le format de représentation des données (XML, JSON, …) mais aussi la version du service qu’il utilise. De cette manière, l’URL reste inchangée ce qui est important avec des services REST. [...] [...] Versioning des Services REST. Sur le Blog Octo, Benjamin Magan nous propose une stratégie pour le versioning des Services REST. La technique proposée est élégante et repose sur la négociation du contenu et l’entête « Content-Type ». Le client indique à l’aide cet entête, non seulement le format de représentation des données (XML, JSON, …) mais aussi la version du service qu’il utilise. De cette manière, l’URL reste inchangée ce qui est important avec des services REST. [...]

]]> Par : JY Cr http://blog.octo.com/versioning-de-services-rest/comment-page-1/#comment-3931 JY Cr Thu, 10 Feb 2011 21:37:39 +0000 http://blog.octo.com/?p=2838#comment-3931 2 petites remarques sur ce vieil article : - Concernant la gestion de version via paramètre Header "Accept", c'est ce que préconise la norme HTTP ( http://tools.ietf.org/html/rfc2616#section-14.1 ) Mais la norme préconise plutôt l'utilisation de la partie "accept-extension". Ce qui donnerait dans l'exemple du service : GET http://.../albums/12133 Accept : application/vnd.octo.music+xml;level=1 Apache semble d'ailleurs prendre en compte ce paramètre : - "Sélectionner les variantes possédant le paramètre de média "level" le plus élevé (utilisé pour préciser la version des types de média text/html)." http://httpd.apache.org/docs/current/content-negotiation.html - "level an integer specifying the version of the media type. For text/html this defaults to 2, otherwise 0." http://httpd.apache.org/docs/2.2/mod/mod_negotiation.html - pour répondre à "c'est intestable automatiquement par un navigateur", si des solution comme l'extension "Poster" n'est pas envisageable, on peut envisager de mettre en œuvre le principe de surcharge via query String de la même manière que "X-HTTP-Method-Override" A part ça ... concernant "Dans un article futur nous pourrons décrire l’architecture technique/applicative impliquée par la gestion de versions via Accept Header." ... je n'ai pas trouvé l'article :) 2 petites remarques sur ce vieil article :

- Concernant la gestion de version via paramètre Header « Accept », c’est ce que préconise la norme HTTP ( http://tools.ietf.org/html/rfc2616#section-14.1 )
Mais la norme préconise plutôt l’utilisation de la partie « accept-extension ». Ce qui donnerait dans l’exemple du service :

GET http://…/albums/12133
Accept : application/vnd.octo.music+xml;level=1

Apache semble d’ailleurs prendre en compte ce paramètre :
- « Sélectionner les variantes possédant le paramètre de média « level » le plus élevé (utilisé pour préciser la version des types de média text/html). »
http://httpd.apache.org/docs/current/content-negotiation.html
- « level an integer specifying the version of the media type. For text/html this defaults to 2, otherwise 0. »
http://httpd.apache.org/docs/2.2/mod/mod_negotiation.html

- pour répondre à « c’est intestable automatiquement par un navigateur », si des solution comme l’extension « Poster » n’est pas envisageable, on peut envisager de mettre en œuvre le principe de surcharge via query String de la même manière que « X-HTTP-Method-Override »

A part ça … concernant « Dans un article futur nous pourrons décrire l’architecture technique/applicative impliquée par la gestion de versions via Accept Header. » … je n’ai pas trouvé l’article :)

]]> 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

]]>