Six contraintes de guidage définissent un système RESTful. Ces contraintes restreignent la manière dont le serveur peut traiter et répondre aux demandes des clients, de sorte qu’en opérant dans le cadre de ces contraintes, le système obtient des propriétés non fonctionnelles souhaitables, telles que les performances, l’évolutivité, la simplicité, la modifiabilité, la visibilité, la portabilité et la fiabilité. Si un système viole l’une des contraintes requises, il ne peut pas être considéré comme RESTful.,

L’officiel RESTE les contraintes sont comme suit:

Client–serveur architectureEdit

Le principe du client–serveur contraintes est la séparation des préoccupations. La séparation des problèmes d’interface utilisateur des problèmes de stockage de données améliore la portabilité des interfaces utilisateur sur plusieurs plates-formes. Il améliore également l’évolutivité en simplifiant les composants du serveur., Peut-être le plus important pour le Web est que la séparation permet aux composants d’évoluer indépendamment, supportant ainsi L’exigence à L’échelle D’Internet de plusieurs domaines organisationnels.

StatelessnessEdit

dans une interaction client–serveur, l’état est composé d’un État intrinsèque et d’un État extrinsèque. L’état intrinsèque, appelé état de ressource, est stocké sur le serveur et se compose d’informations indépendantes du contexte du serveur, ce qui le rend partageable avec tous les clients du serveur., L’état extrinsèque, appelé état de l’application, est stocké sur chaque client et se compose d’informations qui dépendent du contexte du serveur et ne peuvent donc pas être partagées. Les Clients sont responsables de transmettre l’état de l’application au serveur lorsqu’il en a besoin. La contrainte de stockage de l’état de l’application sur le client plutôt que sur le serveur rend la communication sans état.

CacheabilityEdit

comme sur le World Wide Web, les clients et les intermédiaires peuvent mettre en cache les réponses., Les réponses doivent, implicitement ou explicitement, se définir comme pouvant être mises en cache ou non, afin d’empêcher les clients de fournir des données périmées ou inappropriées en réponse à d’autres demandes. Une mise en cache bien gérée élimine partiellement ou complètement certaines interactions client-serveur, améliorant encore l’évolutivité et les performances.

Layered systemEdit

un client ne peut généralement pas dire s’il est connecté directement au serveur final ou à un intermédiaire en cours de route., Si un proxy ou un équilibreur de charge est placé entre le client et le serveur, cela n’affectera pas leurs communications et il ne sera pas nécessaire de mettre à jour le code client ou serveur. Les serveurs intermédiaires peuvent améliorer l’évolutivité du système en activant l’équilibrage de charge et en fournissant des caches partagés. En outre, la sécurité peut être ajoutée en tant que couche au-dessus des services web, séparant la logique métier de la logique de sécurité. L’ajout de la sécurité en tant que couche distincte applique les stratégies de sécurité. Enfin, les serveurs intermédiaires peuvent appeler plusieurs autres serveurs pour générer une réponse au client.,

Code à la demande (facultatif)modifier

Les serveurs peuvent temporairement étendre ou personnaliser les fonctionnalités d’un client en transférant du code exécutable: par exemple, des composants compilés tels que des applets Java, ou des scripts côté client tels que JavaScript.

Uniforme interfaceEdit

L’interface unique contrainte est essentielle à la conception de tout système Reposant. Il simplifie et découple l’architecture, ce qui permet à chaque pièce d’évoluer indépendamment., Les quatre contraintes de cette interface uniforme sont les suivantes:

identification des ressources dans les requêtes les ressources individuelles sont identifiées dans les requêtes, par exemple en utilisant des URI dans les services web RESTful. 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 à partir de sa base de données en HTML, XML ou JSON—dont aucune n’est la représentation interne du serveur., Manipulation des ressources via des représentations lorsqu’un client détient une représentation d’une ressource, y compris les métadonnées attachées, il dispose de suffisamment d’informations pour modifier ou supprimer l’état de la ressource. Messages auto-descriptifs chaque message contient suffisamment d’informations pour décrire comment traiter le message. Par exemple, l’analyseur à appeler peut être spécifié par un type de média., Hypermédia en tant que moteur d’état d’application (HATEOAS) ayant accédé à un URI initial pour L’application REST—analogue à un utilisateur web humain accédant à la page d’accueil d’un site web—un client REST devrait alors pouvoir utiliser dynamiquement les liens fournis par le serveur pour découvrir toutes les ressources disponibles dont il a besoin. Au fur et à mesure que l’accès progresse, le serveur répond avec du texte qui inclut des hyperliens vers d’autres ressources actuellement disponibles. Il n’est pas nécessaire que le client soit codé en dur avec des informations concernant la structure ou la dynamique de l’application.