Une conception RESTful améliore les performances des APIs, réduit les efforts de développement et diminue le support opérationnel nécessaire via le développement d’applications Web, de services Web et d’API Web. Avec des contraintes RESTful éprouvées, les équipes peuvent créer des systèmes évolutifs, omniprésents et prolifiques.
REST nécessite une nouvelle mentalité de développement, c’est pourquoi de nombreuses implémentations d’APIs ne sont pas vraiment basées sur des contraintes ou des principes REST, et ne répondent pas aux attentes d’évolutivité, d’évolutivité et d’interopérabilité. Si nous suivons les bonnes pratiques et travaillons avec des outils RESTful, les équipes peuvent facilement concevoir, mettre à niveau et connecter des API RESTful.
REST contraint le système à :
- Interactions client-serveur
- Communications apatrides
- Données pouvant être mises en cache
- Interfaces uniformes
- Systèmes en couches
- Code à la demande
-Cela pourrait vous intéresser : REST vs SOAP-
Chaque contrainte ajoute des propriétés avantageuses pour le système Web. En implémentant des contraintes, les équipes peuvent construire des systèmes simples, fiables, réalisables, utilisables, accessibles, évolutifs et faciles à entretenir. Dans le tableau suivant, nous pouvons voir comment les contraintes REST peuvent améliorer les propriétés de notre système pour nous :
|
En appliquant cette contrainte : |
Nous obtenons les caractéristiques de système suivantes : |
| Client-Serveur | Simple, évolutif et évolutif |
| Sans état | Simple, visible, facile à entretenir, fiable et évolutif |
| Cache | Visible, évolutif et efficace |
| Interface / Contacts uniformes | Simple, utilisable, visible, accessible, évolutif et fiable |
| Système en couches | Flexible, évolutif, fiable et efficace |
| Code-sur-demande |
Évolutif |
Tableau 1 : Contraintes REST et propriétés système
Lors du développement d’API, d’applications Web ou de services Web, les développeurs appliquent de manière inégale les contraintes REST. Par exemple, une application Web peut avoir du code à la demande (par exemple, JavaScript côté client), une conception de système en couches et des interactions client-serveur, mais d’un autre côté, elle peut ne pas implémenter uniformément les interfaces et les données pouvant être mises en cache.
“Si le bouton ‘retour‘ ne fonctionne pas, votre application Web ou API n’est pas entièrement RESTful.”
Les APIs peuvent implémenter des interfaces uniformes, des interactions client-serveur et des systèmes en couches, mais ne peuvent pas implémenter des communications sans état ou des données pouvant être mises en cache. Si votre client API doit être associé à une session persistante, ou si votre serveur ne vérifie pas le dernier en-tête modifié avant de répondre, votre API n’est pas complètement RESTful.
Communications sans état
Lorsque les communications sont sans état, chaque demande a lieu de manière isolée et le client est responsable du maintien de l’état. La demande du client contient toutes les informations requises dans le processus de demande, et un serveur RESTful ne conserve pas les informations d’état local des demandes passées.
Un essai par le feu pour les communications sans état désactive les cookies de session et détermine si l’API ou le service Web fonctionnent toujours comme prévu.
Les APIs, services et applications RESTful peuvent toujours exposer des états. Cependant, les informations d’état doivent être intégrées dans des représentations de liens hypertexte (par exemple, des URL, des messages hrfs). En transférant explicitement le statut du client, le message de réponse provient explicitement d’un chemin opérationnel validé à travers le système jusqu’au client final.
Avec les communications sans état, le contexte partagé temporairement n’est pas stocké par le serveur. Étant donné que le contexte d’état temporaire doit être envoyé à plusieurs reprises dans les demandes, les communications sans état augmentent le trafic réseau. Mais avec une augmentation de la connectivité réseau, les avantages sont plus importants que les coûts.
Données pouvant être mises en cache
Les systèmes RESTful identifient les données comme pouvant être mises en cache et respectent les balises de cache. Les données pouvant être mises en cache réduisent le trafic réseau et la charge sur le système back-end. Les nœuds intermédiaires peuvent renvoyer des données mises en cache en faveur des serveurs principaux, augmentant ainsi l’évolutivité, la disponibilité, la fiabilité et les performances. Dans un système RESTful, les intermédiaires reconnaissent les nouvelles informations, les opérations idempotentes (par exemple, GET) et la gestion des versions de schéma.
Interfaces uniformes
Bien que la contrainte d’interface uniforme soit la contrainte REST la plus décisive et la plus visible, c’est généralement la raison pour laquelle les principes et techniques RESTful ne sont pas complètement respectés.
Interfaces uniformes :
- Identifier les ressources
- Manipuler les ressources par des représentations
- Afficher des messages auto descriptifs
- Faites confiance à l’hypermédia comme moteur de l’état de l’application (HATEOAS)
Des interfaces uniformes doivent identifier le comportement et la sémantique du message sans examiner le corps du message. L’URL ou l’URI doit déclarer que la ressource est manipulée. Les interfaces uniformes ne dépendent pas de l’état du message stocké. Les interfaces uniformes sont basées sur des messages standard (par exemple, GET, HEAD, POST, DELETE) et communiquent des informations sur le type de média de processus.
Lors de l’application de couches de contraintes REST sur HTTP et les URL, les systèmes RESTful sont optimisés via le transfert de données hypermédias, même s’ils ne sont pas optimaux pour d’autres interactions.
Système en couches
Grâce à la création de systèmes en couches, les équipes peuvent mettre à niveau les composants client et serveur de manière indépendante. Un modèle de conception d’API (API Façade) masque la complexité de l’implémentation interne et présente une interface simple aux consommateurs. Les interfaces API RESTful simples masquent plusieurs bases de données principales et des services supplémentaires (voir Figure 1).
Grâce à l’utilisation d’un modèle de conception d’API (API Façade), les équipes pourront se connecter facilement aux systèmes existants en utilisant des techniques de méditation complexes, mais aussi en proposant une API simple et conviviale aux consommateurs. Sous le capot, la solution peut assembler et orchestrer des services et transformer des messages.
Le modèle de conception d’API (API Façade) permet aux équipes de mettre à l’échelle chaque couche de l’architecture de manière indépendante et d’appliquer des politiques d’infrastructure (par exemple, autorisations, authentifications, temps de réponse et limites de débit) par service système ou API. API Façade peut limiter la complexité du système et simplifier encore plus la complexité de l’intégration en appliquant les principes et contraintes RESTful au modèle de conception de l’API.
Figure 1 : Modèle de façade API
Code-sur-demande
Code-sur-demande ou Code-on-Demand permet aux clients d’étendre les fonctionnalités en téléchargeant et en exécutant du code localement. En activant le code à la demande, le système diminue le nombre de caractéristiques pré-implémentées requises et améliore la capacité de mise à niveau du système. En téléchargeant et en exécutant JavaScript côté client ou dans des plugins au sein d’un serveur ou du client REST, nous respectons les contraintes REST.
L’utilisation de contraintes REST peut faciliter le travail de notre équipe et améliorer considérablement nos systèmes. Une conception RESTful rendra nos API et nos services Web plus efficaces, et nous réduirons également considérablement les efforts de développement. Voulez-vous réaliser un design RESTful ? Téléchargez notre guide.
