Les API REST

Le REST c'est quoi ?

Pour mieux comprendre la suite de cet article, il faut savoir ce qu’est REST. REST est l’acronyme de “Representational State Transfer”.

Afin de mieux comprendre ce qu'est le REST, commençons par un bref historique. Le REST est l'acronyme de "Representational State Transfer" inventé par Roy T. Fielding . Roy T. Fielding participe de puis 1994 aux travaux du W3C sur les sujets URI, HTTP, HTML et WebDAV et a été le co-fondateur du projet Apache . REST décrit les caractéristiques du Web qui en ont fait son succès. L'explication de la signification de REST telle que donnée par Roy T. Fielding est la suivante : "Representational State Transfer évoque l'image du fonctionnement d'une application Web bien construite : un réseau de pages Web (une machine à états finis virtuelle) où l'utilisateur progresse dans l'application en cliquant sur des liens (transition entre états) ce qui provoque l'affichage de la page suivante (représentant le nouvel état de l'application) à l'utilisateur qui peut alors l'exploiter".

Cependant, il faut faire attention, Le REST est un style d’architecture logiciel, c’est l’architecture originelle du web et non un standard.

Donc, il n'existe pas de spécifications de REST. Il faut d'abord déterminer comment fonctionne le style REST avant de vouloir concevoir des applications ou des services web. Bien que REST ne soit pas un standard, il utilise des standards. En particulier :

• URI comme syntaxe universelle pour adresser les ressources,

• HTTP un protocole sans état (stateless) avec un nombre très limité d'opérations,

• Des liens hypermedia dans des documents (X)HTML et XML pour représenter à la fois le contenu des informations et la transition entre états de l'application,

• Les types MIME comme text/xml, text/html, image/jpeg, application/pdf, video/mpeg pour la représentation des ressources.

REST concerne l'architecture globale d'un système. Il ne définit pas la manière de réaliser dans les détails. En particulier, des services REST peuvent être réalisés en .NET, JAVA, CGI ou COBOL. Vous avez sans doute déjà  réalisé des services REST sans le savoir.

Pour la suite de cette article, il faut comprendre plusieurs points :

La ressource

Le composant

Les types MIME

Le Content-Type ou MIME Type est très important puisque c'est lui qui est utilisé par le navigateur pour déterminer le type du fichier, pas l'extension. C'est en fonction de ce type de fichier que le navigateur  déterminera l'action à accomplir (visualisation, téléchargement, etc..). Lorsque la même ressource existe sous plusieurs représentations ou plusieurs langages, il est aussi possible à l'agent utilisateur de "négocier" avec le serveur la représentation qui sera fournie. Les types MIME sont attribués par l'IANA .

L'URI

L’uri ou Uniform Ressource Identifier est une courte chaîne de caractère qui va permettre d’identifier une ressource de manière permanente sur un réseau, physique ou abstraite, même si la ressource est déplacée ou supprimée. Les URI se composent de 2 sous-ensembles URL et URN dont la syntaxe détaillée est décrite ici . Connaître l’URI suffit pour agir sur la ressource.

Cette notion d'URI est fondamentale car c'est le système global et unique d'identification du Web. L'URI est la pierre angulaire de l'architecture Web. Le système d'URI a été largement déployé depuis les débuts du Web et les avantages des URI sont nombreux : liens, favoris, mécanismes de cache, indexation par les moteurs de recherches. En utilisant les URI, il est possible de déployer une application partout dans le monde sans infrastructure additionnelle comme des annuaires ou des "registries". Déployer un autre système de nommage qui aurait les mêmes propriétés que les URI serait très coûteux.

HTTP

HTTP va fournir les opération nécessaires à la manipulation de la ressource :

• GET pour récupérer la ressource
• POST pour créer la ressource
• PUT pour modifier la ressource
• DELETE pour supprimer la ressource.

De ces grands thèmes découlent quelques grands principes :

• Chaque ressource doit avoir un identifiant unique ce qui permet de générer des urls uniques pour chaque action sur une ressource particulière.
• Les ressources doivent être liées les unes aux autres par des liens. Par exemple, si vous présentez une collection de ressources, vous devez fournir une url unique pointant sur chacune des ressources.
• On peut traiter les collections de ressources comme des ressources elles même.
• chaque opération est auto-suffisante : il n’y a pas d’état.

Enfin, il ne faut pas oublier qu'une architecture REST se doit d'être "stateless", c'est à dire que chaque transaction, ou chaque action doit être traitée de manière indépendante. Par exemple, l'architecture REST ne permet pas de définir un flux d'action. C'est au client utilisant cette architecture de la définir comme il le souhaite.

Quelques définitions

Le succès de l'Internet a engendré une pléthore de concepts, de sigles et de promesses dans le domaine de l'architecture des systèmes. Voici quelques définitions pour s'y retrouver.

Services Web

Le terme Services Web a été introduit pour indiquer une interaction entre machines qui ne nécessite pas d'intervention humaine. Les machines parlent aux machines. La plupart des autres concepts ont été inventés pour "standardiser" ce dialogue.

XML

XML fournit une syntaxe unique pour les données sans adhérence avec un logiciel particulier. XML présente comme HTML la particularité de véhiculer les données ET leur description. Ce "gaspillage" s'est révélé très efficace.  XSLT et CSS permettent de transformer et de présenter les données XML en fonction de leur usage. Plus de détails...

SOA - Service-oriented Architecture

SOA ou Architecture orientée Services est un style d'architecture destiné à fournir un couplage lâche (loose coupling) entre les composants d'un système. Un service est une fonction métier sans état (stateless) qui  accepte des demandes et renvoie des réponses au travers d'un interface bien défini. Les services ne doivent pas dépendre de l'état d'autres fonctions ou services. C'est ce qui permet de les combiner (orchestration) pour obtenir des traitements plus complexes. Il ne suffit pas de découper un système en blocs fonctionnels indépendants pour obtenir une architecture orientée services. Il faut aussi décrire les mécanismes de nommage, d'adressage et d'échange qui permettent ce découplage. Sur le modèle Client Serveur, un exemple de succès est le RSS (plus de détails...) qui permet un découplage parfait entre le producteur et le consommateur de données alors que CORBA/DCOM sont des échecs sérieux.

EAI - Enterprise Application Integration

L'EAI est un ensemble d'outils et de méthodes destiné à consolider, moderniser et coordonner les applications existantes dans une entreprise. Trop souvent, ces outils ne font qu'ajouter une couche supplémentaire de logiciels sans diminuer la complexité des systèmes. Le meilleur EAI que je connaisse est tout simplement XML+HTTP.

SOAP

SOAP est un style d'architecture qui permet d'échanger des messages XML entre applications selon le modèle RPC (Remote Procedure Call). SOAP ne respecte ni le style REST ni même le style SOA puisque c'est un moyen de véhiculer des interfaces RPC spécifiques d'une application dans un tuyau standard. Il est donc à terme condamné à s'aligner ou à disparaître. Voir ici pourquoi SOAP est quand même un standard W3C : édifiant! Si l'interopérabilité avec SOAP est indispensable, il est facile d'ajouter des connecteurs SOAP sur une architecture REST. Il est à noter que de nombreux vendeurs "poussent" SOAP car très proche des anciens concepts et essaient de lui trouver une "raison d'être" face à REST . La démonstration est très loin d'être convaincante.

Points forts et inconvénient

Roy Fielding précise dans sa thèse les avantages de ce style d'architecture. Citons par exemple :

• L’application est plus simple à maintenir, car les liens sont mieux structurés, et de façon universelle ; les liens sont le moteur de l’état de l’application.

• L’absence de gestion d’état du client sur le serveur conduit à une consommation de mémoire inférieure, une plus grande simplicité et donc à une capacité plus grande de répondre à un grand nombre de requêtes simultanées.

• L’absence de gestion d’état du client sur le serveur permet une répartition des requêtes sur plusieurs serveurs : une session client n’est pas à maintenir sur un serveur en particulier (via une sticky session d’un loadbalancer), ou à propager sur tous les serveurs (avec des problématiques de rafraîchissement de session). Cela permet aussi une meilleure évolutivité et tolérance aux pannes (un serveur peut être ajouté facilement pour augmenter la capacité de traitement, ou pour en remplacer un autre).

• L’utilisation du protocole HTTP qui permet de tirer partie de son enveloppe et ses entêtes. C'est à l’opposé de SOAP qui ne présuppose pas un protocole : SOAP réinvente un protocole via une enveloppe, des entêtes et un document, à l’intérieur du protocole réseau l’hébergeant (la plupart du temps HTTP). Il ne bénéficie donc pas des caractéristiques HTTP, gérées par l’infrastructure réseau (notamment les proxy supportant le cache côté serveur pour des performances plus importantes).

• L’utilisation d’URI comme représentant d’une ressource, permet la mise en place de serveurs de cache.

Cependant comme toutes choses, des contraintes existes sur ce types d'architectures :

• La nécessité pour le client de conserver localement toutes les données nécessaires au bon déroulement d’une requête, ce qui induit une consommation en bande passante réseau plus grande. S’il est possible de coupler une application web REST à un service extérieur assurant la permanence des données lors de la durée d’une session, par exemple une base de données ou un cookie, on pourrait cependant considérer que l’utilisation d’un tel service pour gérer des données relatives à une session ouverte par le client serait en violation de la philosophie de REST. REST préférera l’utilisation de tableaux codés en Javascript présents dans la mémoire du navigateur client.
• L’utilisation d’un formulaire HTML envoyant ses données avec une méthode comme DELETE ne peut être compris par la plupart des navigateurs. Pour pallier ce problème on émule ce comportement avec un champ caché qui transmettra le type de méthode d’envoi des données à l’application.

Cependant, malgré les contraintes de REST, beaucoup d'application se sont largement inspirées par elle.

Mise en place d'une API REST

Cet ensemble de grands principes architecturaux vont vous permettre de mettre en place facilement une API REST.

Une API doit vous permettre d'utiliser les ressources d'une application web depuis une autre application (web ou non). De nombreux formats d'échanges ont été inventés. On peut citer SOAP et XML-RPC pour ce qui concerne les plus connus. Pourtant, REST s'est aujourd'hui imposé comme un standard de fait. Cela tiens à plusieurs raisons : sa simplicité d'utilisation, le fait que REST ne fait usage que du protocole HTTP, requêtes sans état (ou stateless comme nous venons de le voir).

Aujourd'hui, des entreprise comme Google, Twitter ou facebook en font usage pour leur API publique. Et REST ne cesse de se démocratiser

Pour mettre en place une interface REST avec le framework Django, il existe plusieurs possibilités :

Django-Piston

Django Piston est une application Django qui permet de mettre en place facilement une API REST sur un projet Django. Il implémente oauth pour l’authentification (qui est le standard pour les API REST) et est utilisé notamment par Libération et Bitbucket.

Django Tastipie

Django Tastypie est le concurrent directe de django-piston, jugé plus avancé que son concurrent, il propose une sérialisation “out of the box” des données et est particulièrement performant quand l’API à mettre en place est proche du modèle de donnée.