Si vous avez déjà manipulé les flux de syndication de Flickr, vous avez appelé des URL de la forme suivante :
- Flux RSS 2.0 : flickr.com/…/photos_public.gne?id=…&format=rss_200
- Flux Atom 0.3 : flickr.com/…/photos_public.gne?id=…&format=atom_03
Eh bien il est possible d’utiliser d’autres valeurs du paramètre « format » de l’URL pour obtenir les données non pas en RSS ou Atom, mais dans un format plus simple à manipuler sur votre plateforme.
Le premier exemple intéressant va dans le sens de la nouvelle version « serialized php » de l’API de Yahoo :
php_serial
Mais vous pouvez tenter toute sorte de formats :
Malheureusement, ce n’est valable que pour les flux de syndication, et pas encore pour l’API de Flickr, mais cela ne saurait tarder, ils travaillent dessus.
Cela devrait à n’en pas douter booster la création d’applications exploitant l’API Flickr.
Alors que REST semble recevoir de plus en plus de suffrages face à la lourdeur et complexité de la constellation WS-* qui gravite autour de SOAP[Voir [notre étude sur les Web Services, dont nous allons prochainement publier une mise à jour]], voilà qui pourrait bien favoriser l’éclosion d’une nouvelle race de Web Services.
Il est en effet bien plus simple de générer un tableau Javascript à partir de contenu au format json que de parser du XML. Sans compter l’économie en bande passante et en temps de traitement, tant côté client que serveur.
Par contre, il manque deux choses pour que le modèle d’architecture REST soit respecté :
-# le type de contenu devrait être correctement indiqué dans l’en-tête HTTP de la réponse du service web (Content-Type : xxx)
-# et de même, le client devrait indiquer le format qu’il désire dans l’en-tête HTTP de sa requête et non dans une variable GET.
L’identificateur du format désiré (json, xml, rdf, …) est une méta-donnée de représentation et non pas une identification de la ressource (dans l’URL). Pour faire une analogie, on retrouve un peu ici le problème de séparation entre contenu et présentation des outils de gestion de contenu Web, la spécification HTTP prévoit une en-tête pour ça (Accept)[[Enfin, mais c’est assez subjectif, cela fait des URLs plutôt moches…]].