REST est l’acronyme de REpresentational State Transfer. C’est un style architectural pour les systèmes hypermédia distribués et a été présenté pour la première fois par Roy Fielding en 2000 dans sa célèbre thèse.

comme tout autre style architectural, REST a également ses propres 6 contraintes de guidage qui doivent être satisfaites si une interface doit être référencée comme RESTful. Ces principes sont énumérés ci-dessous.,

Principes directeurs de REST

1. Client–serveur – en séparant les problèmes d’interface utilisateur des problèmes de stockage de données, nous améliorons la portabilité de l’interface utilisateur sur plusieurs plates-formes et améliorons l’évolutivité en simplifiant les composants du serveur.
2. Sans état – chaque requête du client au serveur doit contenir toutes les informations nécessaires pour comprendre la requête et ne peut tirer parti d’aucun contexte stocké sur le serveur. L’état de Session est donc entièrement conservé sur le client.,
3. Cacheable – les contraintes de Cache exigent que les données d’une réponse à une requête soient implicitement ou explicitement étiquetées comme cacheable ou non cacheable. Si une réponse peut être mise en cache, un cache client a le droit de réutiliser ces données de réponse pour des requêtes équivalentes ultérieures.
4. interface uniforme – en appliquant le principe de généralité du génie logiciel à l’interface des composants, l’architecture globale du système est simplifiée et la visibilité des interactions est améliorée., Afin d’obtenir une interface uniforme, de multiples contraintes architecturales sont nécessaires pour guider le comportement des composants. REST est défini par quatre contraintes d’interface: identification des ressources; manipulation des ressources par des représentations; messages auto-descriptifs; et, hypermédia comme moteur de l’état de l’application.
5. système en couches – le style système en couches permet à une architecture d’être composée de couches hiérarchiques en contraignant le comportement des composants de telle sorte que chaque composant ne puisse pas « voir” au-delà de la couche immédiate avec laquelle il interagit.,
6. Code à la demande (facultatif) – REST permet d’étendre les fonctionnalités client en téléchargeant et en exécutant du code sous forme d’applets ou de scripts. Cela simplifie les clients en réduisant le nombre de fonctionnalités devant être pré-implémentées.

Resource

l’abstraction clé des informations dans REST est une ressource. Toute information qui peut être nommée peut être une ressource: un document ou une image, un service temporel, une collection d’autres ressources, un objet non virtuel (par exemple une personne), etc., REST utilise un identificateur de ressource pour identifier la ressource particulière impliquée dans une interaction entre les composants.

l’état de la ressource à un horodatage particulier est connu sous le nom de représentation de ressource. Une représentation se compose de données, de métadonnées décrivant les données et de liens hypermédia qui peuvent aider les clients à passer au prochain état souhaité.

le format de données d’une représentation est appelé type de support. Le type de support identifie une spécification qui définit la façon dont une représentation doit être traitée. Une API vraiment RESTful ressemble à hypertext., Chaque unité d’information adressable porte une adresse, soit explicitement (par exemple, les attributs link et id) ou implicitement (par exemple, dérivé de la définition du type de média et de la structure de représentation).

selon Roy Fielding:

L’hypertexte (ou hypermédia) désigne la présentation simultanée d’informations et de contrôles tels que l’information devient l’affordance par laquelle l’utilisateur (ou l’automate) obtient des choix et sélectionne des actions. N’oubliez pas que l’hypertexte n’a pas besoin d’être HTML (ou XML ou JSON) sur un navigateur., Les Machines peuvent suivre des liens lorsqu’elles comprennent le format des données et les types de relations.

de plus, les représentations de ressources doivent être auto-descriptives: le client n’a pas besoin de savoir si une ressource est un employé ou un appareil. Il devrait agir sur la base du type de média associé à la ressource. Donc, en pratique, vous finirez par créer de nombreux types de médias personnalisés-normalement un type de média associé à une ressource.

Chaque type de support définit un traitement par défaut du modèle., Par exemple, HTML définit un processus de rendu pour l’hypertexte et le comportement du navigateur autour de chaque élément. Il n’a aucun rapport avec les méthodes de ressources GET/PUT/POST/DELETE/ other autre que le fait que certains éléments de type média définiront un modèle de processus qui va comme « les éléments d’ancrage avec un attribut href créent un lien hypertexte qui, lorsqu’il est sélectionné, appelle une demande de récupération (GET) sur L’URI correspondant à L’attribut href, »

méthodes de ressources

Une autre chose importante associée à REST est les méthodes de ressources à utiliser pour effectuer la transition souhaitée. Un grand nombre de personnes associent à tort les méthodes de ressources aux méthodes HTTP GET/PUT/POST/DELETE.

Roy Fielding n’a jamais mentionné de recommandation concernant la méthode à utiliser dans quelle condition. Tout ce qu’il souligne est qu’il devrait être interface uniforme. Si vous décidez que HTTP POST sera utilisé pour mettre à jour une ressource – plutôt que la plupart des gens recommandent HTTP PUT – tout va bien et l’interface de l’application sera RESTful.,

idéalement, tout ce qui est nécessaire pour changer l’état de la ressource doit faire partie de la réponse de L’API pour cette ressource – y compris les méthodes et dans quel état elles quitteront la représentation.

Une API REST doit être saisie sans aucune connaissance préalable au-delà de l’URI initial (signet) et de l’ensemble des types de médias normalisés appropriés au public cible (c’est-à-dire devant être compris par tout client pouvant utiliser L’API)., À partir de ce moment, toutes les transitions d’état d’application doivent être pilotées par la sélection par le client des choix fournis par le serveur qui sont présents dans les représentations reçues ou implicites par la manipulation par l’utilisateur de ces représentations. Les transitions peuvent être déterminées (ou limitées) par la connaissance du client des types de médias et des mécanismes de communication des ressources, qui peuvent tous deux être améliorés à la volée (p. ex., code à la demande).,

Une autre chose qui vous aidera lors de la construction D’API RESTful est que les résultats D’API basés sur des requêtes doivent être représentés par une liste de liens avec des informations récapitulatives, et non par des tableaux de représentations de ressources d’origine car la requête ne remplace pas

REST et HTTP ne sont pas les mêmes !!

beaucoup de gens préfèrent comparer HTTP avec REST. REST et HTTP ne sont pas les mêmes.

RESTE !,= HTTP

cependant, parce que REST a également l’intention de rendre le web (internet) plus rationalisé et standard, il préconise d’utiliser les principes REST plus strictement. Et c’est à partir de là que les gens essaient de commencer à comparer REST avec web (HTTP). Roy fielding, dans sa thèse, n’a mentionné nulle part une directive d’implémentation-y compris une préférence de protocole et HTTP. Jusqu’à ce que le temps, vous honorez les 6 Principes directeurs de repos, vous pouvez appeler votre interface RESTful.,

en termes simples, dans le style architectural REST, les données et les fonctionnalités sont considérées comme des ressources et sont accessibles à l’aide D’identificateurs de ressources Uniformes (URI). Les ressources sont utilisées à l’aide d’un ensemble d’opérations simples et bien définies. Les clients et les serveurs échangent des représentations de ressources à l’aide d’une interface et d’un protocole normalisés – généralement HTTP.

Les ressources sont découplées de leur représentation afin que leur contenu soit accessible dans une variété de formats, tels que HTML, XML, texte brut, PDF, JPEG, JSON et autres., Les métadonnées relatives à la ressource sont disponibles et utilisées, par exemple, pour contrôler la mise en cache, détecter les erreurs de transmission, négocier le format de représentation approprié et effectuer une authentification ou un contrôle d’accès. Et surtout, chaque interaction avec une ressource est sans état.

Tous ces principes aident les applications RESTful à être simples, légères et rapides.