REST signifie Transfert d’État Représentatif, un terme inventé par Roy Fielding en 2000. C’est un style d’architecture pour la conception d’applications faiblement couplées sur HTTP, qui est souvent utilisé dans le développement de services Web. REST n’applique aucune règle concernant la façon dont il doit être implémenté au niveau inférieur, il met simplement des directives de conception de haut niveau et vous laisse penser à votre propre implémentation.
Dans mon dernier emploi, j’ai conçu des API RESTful pour une grande entreprise de télécommunications pendant deux bonnes années. Dans ce post, je partagerai mes pensées en dehors des pratiques de conception standard. Vous n’êtes peut-être pas d’accord avec moi sur quelques points, et c’est parfaitement correct. Je serai heureux de discuter de tout ce qui vous vient avec un esprit ouvert.
Commençons par des éléments spécifiques à la conception standard pour clarifier ce que « Roy Fielding » veut que nous construisions. Ensuite, nous discuterons de mes pensées, qui porteront davantage sur des points plus fins pendant que vous concevrez vos API RESTful.
Contraintes architecturales
REST définit 6 contraintes architecturales qui font de tout service Web une véritable API RESTful.
- Interface uniforme
- Client-serveur
- Sans état
- Cachable
- Système en couches
- Code à la demande (facultatif)
Interface uniforme
Au fur et à mesure que le nom de la contrainte s’applique, vous DEVEZ décider de l’interface des API pour les ressources du système qui sont exposées aux consommateurs d’API et qui suivent religieusement. Une ressource dans le système ne devrait avoir qu’un seul URI logique, ce qui devrait fournir un moyen d’extraire des données connexes ou supplémentaires. Il est toujours préférable de synonyme une ressource avec une page Web.
Toute ressource unique ne doit pas être trop grande et contenir tout dans sa représentation. Chaque fois que cela est pertinent, une ressource doit contenir des liens (HATEOAS) pointant vers des URI relatifs pour récupérer des informations connexes.
En outre, les représentations de ressources à travers le système doivent suivre des directives spécifiques telles que les conventions de nommage, les formats de lien ou le format de données (XML ou / et JSON).
Toutes les ressources doivent être accessibles via une approche commune telle que HTTP GET et modifiées de la même manière en utilisant une approche cohérente.
Client-serveur
Cette contrainte signifie essentiellement que l’application cliente et l’application serveur DOIVENT pouvoir évoluer séparément sans aucune dépendance l’une de l’autre. Un client ne doit connaître que les URI de ressources, et c’est tout. Aujourd’hui, c’est une pratique courante dans le développement Web, donc rien de fantaisie n’est requis de votre part. Restez simple.
Sans état
Roy fielding s’est inspiré de HTTP, donc cela se reflète dans cette contrainte. Rendre toutes les interactions client-serveur sans état. Le serveur ne stockera rien sur la dernière requête HTTP effectuée par le client. Il traitera chaque demande comme nouvelle. Pas de session, pas d’historique.
Si l’application cliente doit être une application avec état pour l’utilisateur final, où l’utilisateur se connecte une fois et effectue d’autres opérations autorisées par la suite, chaque demande du client doit contenir toutes les informations nécessaires au service de la demande, y compris les détails d’authentification et d’autorisation.
Cachable
Dans le monde d’aujourd’hui, la mise en cache des données et des réponses est de la plus haute importance partout où elles sont applicables / possibles. La page Web que vous lisez ici est également une version en cache de la page HTML. La mise en cache apporte une amélioration des performances côté client et une meilleure évolutivité pour un serveur car la charge a diminué.
Dans REST, la mise en cache doit être appliquée aux ressources le cas échéant, puis ces ressources DOIVENT se déclarer cachables. La mise en cache peut être implémentée côté serveur ou côté client.
Système en couches
REST vous permet d’utiliser une architecture de système en couches dans laquelle vous déployez les API sur le serveur A, stockez les données sur le serveur B et authentifiez les requêtes dans le serveur C, par exemple. 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.
Code à la demande (facultatif)
Eh bien, cette contrainte est facultative. La plupart du temps, vous enverrez les représentations statiques des ressources sous forme de XML ou de JSON. Mais lorsque vous en avez besoin, vous êtes libre de return executable code pour prendre en charge une partie de votre application, par exemple, les clients peuvent appeler votre API pour obtenir un code de rendu de widget d’interface utilisateur. C’est permis.
Notez que toutes les contraintes ci-dessus sont les plus étroitement liées à WWW (le web). En utilisant des API RESTful, vous pouvez faire la même chose avec vos services Web que vous faites pour les pages Web.