Les architectures des gros noms du Web, souvent basées sur le style REST, sont, dans l’implémentation, bien différente des SOA d’entreprises, majoritairement basées sur SOAP. Mais les APIs REST sont une forme de SOA, dont l’objectif est d’utiliser HTTP comme moyen de communication. On parle alors d’architectures orientées Web : WOA.
L’objectif de cette architecture est de proposer une version plus simple de la SOA, utilisant les caractéristiques et les standards du Web, plutôt que de chercher à les abstraire. L’architecture REST utilise les spécifications originelles du protocole HTTP, plutôt que de réinventer une surcouche comme SOAP :
- L’URI comme identifiant des ressources.
- Les verbes HTTP comme identifiant des opérations.
- Les réponses HTTP comme représentation des ressources.
REST est donc fortement recommandé pour des cas simples où on cherche à effectuer des actions sur un contenu, comme lister, créer, modifier, supprimer des ressources. Pour toutes ces actions on utilisera la commande HTTP adéquat :
- Lire une ressource, ou une collection de ressources (GET).
- Modifier une ressource existante (PUT).
- Créer une ressource (POST).
- Supprimer une ressource (DELETE).
Exemple :
- Un GET http://www.mondomaine.com/clients signifie que je souhaite récupérer la liste des clients disponibles.
- Un GET http://www.mondomaine.com/clients/2 signifie que je souhaite récupérer les informations du client dont l’identifiant est 2.
- Au même titre, un DELETE http://www.mondomaine.com/clients /2 doit supprimer le client 2.
Spécificités REST
Les propriétés d’une API REST sont :
Uniformité : Chaque ressource est identifiée de façon unique par son URL. L’interface est uniforme à tous les niveaux. Tous les éléments communiquent en utilisant la même interface.
Sans état : Une API REST ne doit pas maintenir de session. Cela garantis des appels idempotents.
Mise en cache : Il doit être possible d’utiliser les implémentations standards de cache HTTP.
Client / Serveur : Separation of Concerns : L’API REST n’est pas concernée par l’affichage, les interactions utilisateur et la session.
Layered : La présence de “connecteurs” intermédiaires doit être implicite pour le client et le serveur (composant de cache / sécurité etc…).
RESTFUL
En se basant sur le travail de Roy Fielding, Leonard Richardson a établi un modèle de maturité des services web REST appelé Richardson Maturity Model (RMM). Ce modèle est composé de quatre niveaux permettant d’évaluer une API par rapport aux contraintes REST.
- Niveau 0 : Le protocole HTTP est utilisé uniquement à des fins de transport du message. L’ensemble des données transitent par un seul et unique point d’entrée.
- Niveau 1 : Introduction de la notion de ressources. Il y a donc désormais plusieurs endpoint (URI) par ressource.
- Niveau 2 : Apparition de la notion d’action et d’état, ce qui correspond aux verbes, GET, POST, PUT, DELETE et aux codes http (200, 404, 500…).
- Niveau 3 : Ultime et dernière notion de REST : HATEOAS (Hypertext As The Engine Of Application State). Notre API est « autodocumentée », c’est-à-dire que l’on peut passer d’une action à une autre via des URL transmises par l’API dans les réponses.
Une API RESTful est une API qui respecte toutes les contraintes REST. La très grande majorité du temps, les API sont au niveau 2 du RMM.