REprentational State Transfer

Architecture

Architecture

Pour construire une architecture Rest, Roy fieldling a émis un ensemble de contraines :

Client Serveur

Architecture client serveur Une interface uniforme sépare clients de serveurs. Cette séparation des préoccupations signifie que 1 - Les clients ne sont pas concernés par l’implémentation du stockage de données , qui reste interne à chaque serveur = Portabilité 2 - Serveurs ne sont pas concernés par l'état de l'interface utilisateur ou utilisateur. Des serveurs et des clients peuvent également être remplacés et mis au point de manière indépendante , dans la mesure où l'interface entre eux ne soit pas modifié Permet de faire évoluer le client ou le serveur de façon indépendante La séparation des responsabilités entre le client et le serveur offre un découplage favorable à l’évolution du système dans son ensemble. Ce type d’architecture n’est pas propre au style REST, ce dernier s’en inspire tout simplement.

Sans Etat

Chaque requête doit porter suffisamment d’information pour être comprise par le serveur sans que celui-ci n’ait besoin de retrouver le fruit des interactions précédentes avec ce client en particulier. Cela permet d’assurer une meilleure capacité à monter en charge, mais aussi d’améliorer la robustesse (la perte d’une session est toujours un problème, et sa réplication encore plus…) La communication client - serveur est en outre limitée par aucun contexte du client étant stocké sur le serveur entre les requêtes. Chaque demande de tout client contient toutes les informations nécessaires pour traiter la demande , et l'état de session est maintenu dans le client . Il importe de noter que l'état de session peut être transféré par le serveur à un autre service comme une base de données pour maintenir un état persistant pour une période et permettre l'authentification . Le client commence à envoyer des demandes quand il est prêt à faire la transition vers un nouvel état . Alors une ou plusieurs demandes sont en circulation, le client est considéré comme étant en transition . La représentation de chaque état ​​de l'application contient des liens qui peuvent être utilisés la prochaine fois que le client décide d'engager un nouvel état - transition

Cache

On parle d’architecture distribuée et donc d’échanges réseau. La contrainte du cache est naturellement là pour optimiser les performances. Cette contrainte induit que les réponses du service indiquent au client si elles peuvent être mises en cache ou non, lui laissant la possibilité de ne pas requêter à nouveau si la ressource est présumée encore “ fraîche” Comme sur le World Wide Web , les clients peuvent mettre en cache les réponses . Les réponses doivent donc , implicitement ou explicitement , se définir comme être mis en cache , ou non , pour empêcher les clients de réutiliser les données obsolètes ou inappropriées en réponse à de nouvelles demandes . La mise en cache bien géré partiellement ou élimine complètement certaines interactions client-serveur , améliorant encore l'évolutivité et les performances

Interface uniforme

Cette contrainte augmente encore le découplage entre le client et les ressources en rendant générique la façon d’interagir avec les ressources. Le style REST spécifie sous forme de nouvelles contraintes ce qu’est une interface uniforme. Ces contraintes d’interface sont : Une identification des ressources. Cela permet de faire référence à des ressources de façon non équivoque et de créer des liens pérennes entre ressources. L’utilisation de Représentations pour interagir avec les Ressources. Une ressource peut avoir une ou plusieurs représentations, que le client manipulera et dont il se servira pour communiquer avec le service, lequel agira sur la ressource en conséquence. Messages auto descriptifs. Une réponse à une requête portera par exemple une information sur le type de représentation retourné, permettant au client de savoir comment la traiter. Gestion des transitions par liens hypermédia. Les possibilités d’interactions avec une ressource au travers ses représentations sont décrites dans les messages par des liens hypermédia, permettant au client de “découvrir” ce qui lui est permis de faire.

Système en couches

On parle ici des couches d’une architecture complète. Considérant le cas d’un service REST reposant sur HTTP, ces couches sont par exemple un reverse proxy, un service d’authentification, … Le client ne doit pas avoir besoin de connaître, ni quelle est la première couche avec laquelle il communique, ni combien de couches le séparent des ressources manipulées. D’ailleurs la configuration des couches doit pouvoir évoluer sans impact sur le client. Ici, l’interface unifiée est un des éléments permettant cette souplesse.

Exemple

En suivant les contraintes émises par Roy fielding, on pourrait mettre en place une plateforme d'infrastructure proposant un service Rest de la manière suivante


Infrastructure Rest