REST / Json : Contenu ou présentation ?

Dans l’inconscient collectif, le web reste associé à la notion de « page web » – sous entendu, de fichier html constituant en lui même à la fois données et représentation des données. Pourtant, bien qu’il reste le format de présentation attendu par le client web le plus répondu – ton navigateur, ami lecteur -, le html n’est pas constitutif du protocole HTTP (qui s’articule essentiellement autour de la notion – volontairement large – de « ressource » – et des « verbes » - GET, POST, PUT, etc – définissant les actions possibles sur une ressource), et reste plus un format de présentation (associé aux feuilles de style) qu’un format de données à proprement parler.

Pourtant, bien que presque plus personne ne construise encore un site à base de pages html statiques – le CMS est devenu la norme pour les sites « de contenu », et ne parlons pas des sites de plus en plus nombreux qui constituent plus une application (le back office de votre CMS, les réseaux sociaux etc) qu’une collection de pages – le standard pour le code côté serveur reste de générer du html éventuellement agrémenté d’un peu (voire beaucoup) de Javascript. Mais pour combien de temps encore ?

La ruée vers les API

A peu près tous les acteurs majeurs (Facebook, Google et ses innombrables services, Youtube et tous les sites de partage de vidéo ou autre médias…) présentent maintenant des API pour accéder à leurs services. Ce n’est plus tout à fait une nouveauté certes, mais cette tendance s’intensifie, au point qu’aucun « service » ne peut désormais être pris au sérieux s’il n’expose pas une API. Après une première période – dans laquelle nous somme encore à ce jour – de solutions ad-hoc, d’évolutions perpétuelles et de technologies variées et exotiques, une tendance lourde s’impose petit à petit: REST / Json.

REST (pour « representational state transfert » – oui on aime bien jargonner sur le net) parce ce que quite à utiliser HTTP, autant l’utiliser tel qu’il a été conçu, de façon standard – c’est l’intérêt d’un protocole standardisé n’est-ce pas – plutôt que de réinventer des « protocoles » hétérogènes par dessus.

Json (pour « Javascript object notation« ) parce que c’est un format « léger » (comparé à la verbosité du XML), simple, s’appuyant sur des structures de données existant dans tous les langages de programmation ou presque (bon, ok peut-être pas en COBOL), et surtout natif pour LE langage roi côté serveur, Javascript.

Don’t repeat yourself

Avec la complexification croissante des interfaces utilisateur des applications web – ajaxification à gogo, appel direct via javascript aux APIs de services tiers etc – le développeur se trouve de plus en plus obligé de dupliquer son travail, d’une part pour servir la « page web » (html) initiale, puis pour servir des fragments de html et/ou du json pour les requêtes Ajax. Il lui faut maintenant en plus gérer une API (REST/Json tant qu’à faire, autant partir sur de bonnes bases) pour que d’autres sites – ou d’autres clients web (application mobile anyone ?) – puissent accéder aux services de son application. Or chacun sait que toute répétition est un risque de bug et un poids supplémentaire pour la maintenance et les évolutions. Mais cette répétition est-elle nécessaire ?

Découpler l’applicatif de l’UI

En effet, plutôt que de développer votre « application web » pour qu’elle serve du html puis d’y ajouter tant bien que mal une surcouche « API », pourquoi ne pas d’entrée de jeu séparer une bonne fois pour toute l’application elle-même – n’existant plus que sous forme d’une API REST/json – de l’interface utilisateur, qu’elle soit implémentée de façon « traditionnelle » (une autre appli serveur, cliente de la première et générant du HTML à partir du json), sous forme d’application client navigateur (via un framework javascript tel que Angular JS ou l’un de ses concurrents), ou comme application mobile ?

A première vue tout ça peut sembler inutilement compliqué. Pourtant quand on y pense ce n’est que l’application de deux sains principes d’architecture, la factorisation (don’t repeat yourself) - déjà évoquée plus haut -, et la séparation des responsabilités. Certes les frameworks actuels incitent déjà à cette séparation dans une certaine mesure, mais la frontière n’est pas étanche loin s’en faut et l’implémentation de l’UI reste dépendante de celle du métier, ne serait-ce que sur les choix de technologie. En n’exposant plus l’applicatif que sous la forme d’API REST, on s’assure d’un découplage complet, non seulement au niveau des responsabilités mais aussi – et surtout – au niveau de l’implémentation et des technologies employées respectivement pour l’application et le / les UI, le seul contrat restant entre les deux étant l’API elle-même – API dont, en outre, plusieurs versions peuvent cohabiter, ce qui permet de laisser du temps aux clients pour se mettre à jour.

There’s no silver bullet – but…

Il ne faut pas se leurrer, cette proposition d’architecture n’est pas la solution à tous les problèmes. Malgré le gain espéré du point de vue des « bonnes pratiques » – et donc de la maintenabilité -, on peut se poser la question des coût de développement (puisqu’il faut maintenant au moins deux « applications » pour un site, l’application API et l’application UI) et d’exploitation.

Pour le coût du développement initial c’est assez difficile voire tout à fait impossible à chiffrer, mais si l’on met de côté la mise en place de l’infrastructure nécessairement un peu plus complexe il n’est pas dit que le coût soit au final tellement supérieur – si l’application est de toutes façons supposée fournir une API, il y a même à parier que cette approche permette au final des économies. Sinon, comme pour tout choix de ce genre, il faut tenir compte du coût du développement d’une API a postériori en plus de celui de l’UI « intégrée », puis de celui de la maintenance de cette duplication fonctionnelle ou du portage vers une solution service/client. Par ailleurs, on peut espérer que la généralisation de telles architectures – ou au moins celle des services REST/json – entraine également la généralisation de bibliothèques / mini-frameworks clients permettant de simplifier et standardiser l’implémentation de l’UI. Et, oh surprise, on voit actuellement fleurir de tels composants, en Python (RestORM), Ruby (Her), PHP (Rizeway OREM) etc.

Du point de vue des coûts d’exploitation, il est vrai qu’une telle architecture implique de déployer et d’administrer deux applications web distinctes là où on n’en avait traditionnellement qu’une, mais cela constitue-t-il un tel surcoût ? Dans bon nombre de cas, on peut espérer que la partie serveur de l’UI soit extrêmement simple, voir essentiellement statique dans le cas de l’utilisation d’un framework Javascript côté client, et donc peu coûteuse en administration / hébergement. Pour ce qui est de la partie application / API, générer du json est incomparablement moins couteux que générer des pages HTML dynamiques et on peut donc là aussi espérer optimiser l’hébergement. Quant au déploiement, s’il est vrai qu’on double l’effort, on n’a au moins plus d’inquiétude de casser l’applicatif sur une évolution de l’UI ou réciproquement.

Reste bien sûr la question des performances, et il est clair qu’ajouter une indirection supplémentaire – surtout de cet ordre – n’est pas anodin. On peut certes là aussi « optimiser » avec une bonne configuration des serveurs (et notamment de la résolution dns) mais une requête HTTP ne sera pas aussi rapide qu’une requête directe sur une base SQL locale… Mais si vous avez un besoin pour une API vous ne servez probablement plus votre contenu depuis une base SQL locale (si même vous utilisez encore une base SQL).