thumb|upright=2|Modèle d'information REST. REST () est un style d'architecture logicielle définissant un ensemble de contraintes à utiliser pour créer des services web. Les services web conformes au style d'architecture REST, aussi appelés services web RESTful, établissent une interopérabilité entre les ordinateurs sur Internet. Les services web REST permettent aux systèmes effectuant des requêtes de manipuler des ressources web via leurs représentations textuelles à travers un ensemble d'opérations uniformes et prédéfinies sans état. D'autres types de services web tels que les services web SOAP exposent leurs propres ensembles d'opérations arbitraires.

Les ressources web ont d'abord été définies comme des documents ou des fichiers identifiés par leur URL. Cependant, elles ont aujourd'hui une définition beaucoup plus générique et abstraite qui inclut toute chose ou entité pouvant être identifiée, nommée, adressée ou gérée d'une façon quelconque sur le web. Dans un service web REST, les requêtes effectuées sur l'URI d'une ressource produisent une réponse dont le corps est formaté en HTML, XML, JSON ou un autre format. La réponse peut confirmer que la ressource stockée a été altérée et elle peut fournir des liens hypertextes vers d'autres ressources ou collection de ressources liées. Lorsque le protocole HTTP est utilisé, comme c'est souvent le cas, les méthodes HTTP disponibles sont GET, HEAD, POST, PUT, PATCH, DELETE, CONNECT, OPTIONS et TRACE.

Avec l'utilisation d'un protocole sans état et d'opérations standards, les systèmes REST visent la réactivité, la fiabilité et l'extensibilité, par la réutilisation de composants pouvant être gérés et mis à jour sans affecter le système global, même pendant son fonctionnement.

Le terme a été défini pour la première fois en 2000 par Roy Fielding dans le chapitre 5 de sa thèse de doctorat. La thèse de Fielding a expliqué les principes de REST auparavant connus comme le « modèle objet de HTTP » depuis 1994 et qui ont été utilisés dans l'élaboration des standards HTTP 1.1 et URI. Le terme est censé évoquer comment une application web bien conçue se comporte : c'est un réseau de ressources (une machine à états virtuelle) au sein duquel l'utilisateur évolue en sélectionnant des identifiants de ressources telles que http://www.exemple.com/articles/21 et des opérations sur les ressources telles que GET ou POST (des transitions d'état de l'application) transférant une représentation de la ressource suivante (le nouvel état de l'application) vers l'utilisateur pour être utilisée.

Histoire

Roy Fielding a défini REST en 2000 dans sa thèse de doctorat Architectural Styles and the Design of Network-based Software Architectures à l'université de Californie à Irvine. Il y a développé le style d'architecture REST en parallèle du protocole HTTP 1.1 de 1996 à 1999, basé sur le modèle existant de HTTP 1.0 de 1996.

Lors d'un regard rétrospectif sur le développement de REST, Fielding a déclaré:

Par nature, les styles architecturaux sont indépendants de toute mise en œuvre spécifique, et bien que REST ait été créé dans le cadre du développement des normes Web, la mise en œuvre du Web n'obéit pas à toutes les contraintes du style architectural REST. Des inadéquations peuvent se produire par ignorance ou par inadvertance, mais l'existence du style architectural REST signifie qu'elles peuvent être identifiées avant qu'elles ne deviennent normalisées. Par exemple, Fielding a identifié l'intégration d'informations de session dans les URI comme une violation des contraintes de REST qui peut avoir un impact négatif sur la mise en cache partagée et l'évolutivité du serveur. Les cookies HTTP violent également les contraintes de REST car ils peuvent se désynchroniser de l'état de l'application du navigateur, ce qui les rend peu fiables ; ils contiennent également des données opaques qui peuvent poser des problèmes de confidentialité et de sécurité.

Contraintes architecturales Six contraintes architecturales définissent un système REST. Ces contraintes restreignent la façon dont le serveur peut traiter et répondre aux requêtes du client afin que, en agissant dans ces contraintes, le système gagne des propriétés non fonctionnelles désirables, telles que la performance, l'extensibilité, la simplicité, l'évolutivité, la visibilité, la portabilité et la fiabilité. Un système qui viole une de ces contraintes ne peut pas être considéré comme adhérant à l'architecture REST.

Client–serveur

Les responsabilités sont séparées entre le client et le serveur. Découpler l'interface utilisateur du stockage des données améliore la portabilité de l'interface utilisateur sur plusieurs plateformes. L'extensibilité du système se retrouve aussi améliorée par la simplification des composants serveurs. Mais peut-être encore plus essentiel pour le Web, la séparation permet aux composants d'évoluer indépendamment, supportant ainsi les multiples domaines organisationnels nécessaires à l'échelle d'Internet.

Sans état

La communication client–serveur s'effectue sans conservation de l'état de la session de communication sur le serveur entre deux requêtes successives. L'état de la session est conservé par le client et est transmis à chaque nouvelle requête. Cet état de session conserve les données nécessaire à l'authentification. Les requêtes du client contiennent donc toute l'information nécessaire pour que le serveur puisse y répondre. La visibilité des interactions entre les composants s'en retrouve améliorée puisque les requêtes sont complètes. La tolérance aux échecs est également plus grande. De plus, le fait de ne pas avoir à maintenir une connexion permanente entre le client et le serveur permet au serveur de répondre à d'autres requêtes venant d'autres clients sans saturer l'ensemble de ses ports de communication, ce qui améliore l'extensibilité du système.

Cependant une exception usuelle à ce mode sans état est la gestion de l'authentification du client. Afin que celui-ci n'ait pas à renvoyer ces informations à chacune de ses requêtes, des mécanismes permettent au client de rester authentifié de manière sécurisée. Dans l'exemple d'un site web, les données d'authentification sont stockées dans un cookie de session. Pour des raisons de sécurité, le cookie de session ne stocke qu'un identifiant de session, et non pas les données qui ont servi à l'authentification.

Avec mise en cache

Les clients et les serveurs intermédiaires peuvent mettre en cache les réponses. Les réponses doivent donc, implicitement ou explicitement, se définir comme pouvant être mises en cache ou non, afin d'empêcher les clients de récupérer des données obsolètes ou inappropriées en réponse à des requêtes ultérieures. Une mise en cache bien gérée élimine partiellement voire totalement certaines interactions client–serveur, améliorant davantage l'extensibilité et la performance du système.

En couches

Un client ne peut habituellement pas dire s'il est connecté directement au serveur final ou à un serveur intermédiaire. Les serveurs intermédiaires peuvent améliorer l'extensibilité du système en mettant en place une répartition de charge et un cache partagé. Ils peuvent aussi renforcer les politiques de sécurité.

Avec code à la demande (facultative) Les serveurs peuvent temporairement étendre ou modifier les fonctionnalités d'un client en lui transférant du code exécutable. Par exemple par des applets Java ou des scripts JavaScript. Cela permet de simplifier les clients en réduisant le nombre de fonctionnalités qu'ils doivent mettre en œuvre par défaut et améliore l'extensibilité du système. En revanche, cela réduit aussi la visibilité de l'organisation des ressources. De ce fait, elle constitue une contrainte facultative dans une architecture REST.

Interface uniforme La contrainte d'interface uniforme est fondamentale dans la conception de n'importe quel système REST. Elle simplifie et découple l'architecture, ce qui permet à chaque composant d'évoluer indépendamment. Les quatre contraintes de l'interface uniforme sont les suivantes.

Identification des ressources dans les requêtes Chaque ressource est identifiée dans les requêtes, par exemple par un URI dans le cas des systèmes REST basés sur le Web. Les ressources elles-mêmes sont conceptuellement distinctes des représentations qui sont retournées au client. Par exemple, le serveur peut envoyer des données de sa base de données en HTML, XML ou JSON, qui sont des représentations différentes de la représentation interne de la ressource.

Manipulation des ressources par des représentations Chaque représentation d'une ressource fournit suffisamment d'informations au client pour modifier ou supprimer la ressource.

Messages auto-descriptifs Chaque message contient assez d'information pour savoir comment l'interpréter. Par exemple, l'interpréteur à invoquer peut être décrit par un type de médias.

Hypermédia comme moteur d'état de l'application (HATEOAS) Après avoir accédé à un URI initial de l'application — de manière analogue aux humains accédant à la page d'accueil d'un site web —, le client doit être en mesure d'utiliser dynamiquement les hyperliens fournis par le serveur pour découvrir toutes les autres actions possibles et les ressources dont il a besoin pour poursuivre la navigation. Il n'est pas nécessaire pour le client de coder en dur cette information concernant la structure ou la dynamique de l'application.

Propriétés architecturales Les contraintes architecturales de REST confèrent aux systèmes qui les respectent les propriétés architecturales suivantes :

performance dans les interactions des composants, qui peuvent être le facteur dominant dans la performance perçue par l'utilisateur et l'efficacité du réseau ; extensibilité permettant de supporter un grand nombre de composants et leurs interactions. Roy Fielding décrit l'effet de REST sur l'extensibilité comme suit :

simplicité d'une interface uniforme ; évolutivité des composants pour répondre aux besoins (même lorsque l'application est en cours de fonctionnement) ; visibilité des communications entre les composants par des agents de service ; portabilité des composants en déplaçant le code avec les données ; fiabilité dans la résistance aux pannes du système en cas de pannes des composants, des connecteurs ou des données.

Modèles de classification Plusieurs modèles ont été développés pour aider à classer les API REST en fonction de leur adhésion à divers principes de conception REST, tels que le modèle de maturité de Richardson la classification des API basées sur le protocole HTTP le modèle de maturité W S3

Appliqué aux services web Les API REST basées sur HTTP sont définies par : un URI de base, comme http://api.example.com/collection/ ; des méthodes HTTP standards (par ex. : GET, POST, PUT, PATCH et DELETE) ; un type de médias pour les données permettant une transition d'état (par ex. : Atom, microformats, application/vnd.collection+json, etc.). La nature hypermédia de l'application permet d'accéder aux états suivants de l'application par inspection de la représentation courante. Cela peut être aussi simple qu'un URI ou aussi complexe qu'un applet Java.

Relation entre URI et méthodes HTTP Le tableau suivant affiche comment les méthodes HTTP sont généralement utilisées dans une API REST :