Pourquoi devrions-nous utiliser REST?
Pourquoi devrais-je utiliser REST si je peux faire mon travail avec uniquement des messages et des demandes?
Roy Fielding a blogué avec une certaine frustration sur Les RPC se faisant passer pour REST .
REST exige l'utilisation d'hypertexte, qui évolue très bien car le client et le serveur sont très peu couplés. Avec REST, le serveur est libre de modifier à volonté les ressources exposées. Il n'y a pas d'API fixe au-delà de ce que REST définit lui-même. Le client n'a besoin que de connaître l'URI initial, puis choisit parmi les choix fournis par le serveur pour naviguer ou effectuer des actions. Un serveur peut télécharger du code au client qui facilite la navigation et la représentation de l'état.
Tout cela contraste fortement avec les divers schémas d'appel de procédure distante (RPC) dans lesquels le client et le serveur doivent se mettre d'accord sur un protocole détaillé qui doit généralement être compilé aux deux extrémités (par exemple, les URI d'une forme particulière accessibles dans un ordre particulier) à un extrême, SOAP/WSDL/WS * à l'autre). Cette approche est fragile, car tout changement doit être mis en œuvre à la fois côté serveur et côté client. Il devient rapidement intenable à mesure que le nombre de serveurs et/ou de clients augmente. Les serveurs en particulier souffrent car l'évolution de l'API publiée devient progressivement plus difficile à mesure que la popularité augmente.
À la lumière de ces facteurs, REST est toujours le meilleur choix lorsque cela est possible. Il permet une évolution rapide des serveurs et permet à un nombre astronomique d'applications d'interagir librement sur une base ad hoc (par exemple l'ensemble L'Internet).
Mais qu'en est-il de la partie "quand c'est possible"? REST fonctionne mieux quand il y a un humain dans la boucle. Après tout, un humain a de bonnes chances de pouvoir faire un choix rationnel lorsqu'il est présenté avec un ensemble d'options inconnu auparavant. Les machines ne sont pas n'y sont pas encore. Les protocoles Web RPC sont nés précisément pour menotter les deux côtés à un protocole fixe. Cela permet aux processus automatisés de communiquer plus facilement lorsque l'homme est retiré de l'image. Un RPC est un choix de conception valide lorsqu'une opération purement automatisée est plus important que l'évolution et l'évolutivité (dans le temps Internet et à l'échelle Internet).
Echelle et couplage?
"Échelle" ici est entendu au sens large. Cela comprend le nombre d'utilisateurs et de sessions, oui, mais aussi la taille de l'application et le processus de développement. Un couplage serré présente un sérieux obstacle à la taille de l'application. Il est difficile d'imaginer l'existence de la plus grande application connue, le World-Wide Web, sans le couplage extrêmement lâche offert par l'architecture REST. Des millions de développeurs à travers le monde ont collaboré pour construire cette Cette application prend en charge des milliards d'utilisateurs. Pourtant, les développeurs le font tout en restant parfaitement inconscients les uns des autres (ou du moins ils ne se connaîtraient pas sans StackOverflow;).
Le principe habilitant principal de REST est hypertexte. Les autres éléments de l'architecture existent pour supporter ce principe à très grande échelle (dans tous les sens). Est REST le seul moyen concevable que le Web aurait pu être construit? Non. Mais il se trouve que c'est la norme de facto qui a connu un succès retentissant. Il devrait être le choix par défaut pour toute nouvelle entrée dans l'écosystème, rejeté uniquement après une étude minutieuse et explicite de la conception.
L'utilisation de REST correctement peut aider les composants de votre système à rester correctement découplés et peut évoluer plus facilement à l'avenir que si vous les aviez liés directement les uns aux autres d'une manière typique de type RPC. C'est un choix architectural qui vous devez faire en fonction des besoins de votre application. D'autres ont noté certains des avantages techniques, et ils doivent également être pris en compte.
REST permet une évolution facile d'une conception d'API. Et c'est la clé avec REST - vous créez une API. Certains des commentaires ont touché des aspects de cette pensée, mais n'ont pas réellement donné vie au problème principal. Lorsque vous traitez avec REST, vous créez une API qui serait utilisée par les clients (ou vous-même). Les actions HTTP sur les ressources donnent aux clients une indication claire de la conception et des fonctionnalités de l'API. Par conséquent, lorsque nous utilisons correctement les verbes HTTP appropriés, nous déclarons une API standardisée et compréhensible du point de vue du client.
La découverte est beaucoup plus facile dans REST. Nous avons des documents WADL (similaires à WSDL dans les services Web traditionnels) qui vous aideront à annoncer votre service dans le monde. Vous pouvez également utiliser les découvertes UDDI. Avec le HTTP traditionnel POST et GET, les gens peuvent ne pas connaître vos schémas de demande et de réponse de message pour vous appeler.
Si vos demandes GET ne sont pas idempotent alors la mise en cache HTTP entre votre serveur et vos clients casserait votre application. Les requêtes POST ne sont par définition pas idempotentes, donc les caches HTTP ne mettront pas en cache ces requêtes et résultats: vous bénéficiez toujours des avantages de la mise en cache des requêtes GET, sans casser le protocole de votre application. Grand succès.
Et, si jamais vous avez besoin de supprimer des objets, DELETE sera beaucoup plus facile à lire sur le fil et les journaux qu'une demande POST qui effectue la suppression. Mais les navigateurs Web ne peuvent pas facilement faire de requêtes HTTP avec le verbe DELETE, c'est donc vraiment plus pour les clients que vous avez vous-même programmés.
Vous devez utiliser REST en raison des fonctionnalités et avantages ci-dessous:
Traits
- Protocole client/serveur sans état : Chaque HTTP contient toutes les informations nécessaires pour l'exécuter, ce qui signifie que ni le client ni le serveur n'ont besoin de se souvenir d'un état antérieur pour le satisfaire. Quoi qu'il en soit, certaines applications HTTP intègrent une mémoire cache. Cela configure ce que l'on appelle le protocole client-cache-serveur sans état: il est possible de définir certaines des réponses à des requêtes HTTP spécifiques comme cachable, afin que le client puisse exécuter la même réponse pour des requêtes identiques à l'avenir. Cependant, le fait que l'option existe ne signifie pas qu'elle est la plus recommandée.
- Il existe quatre transactions de données très importantes dans tout système REST et spécification HTTP: POST (créer), GET (lire et consulter), PUT (modifier) et DELETE.
- Les objets dans REST sont toujours manipulés à partir de l'URI . C'est l'URI et aucun autre élément qui est le seul identifiant de chaque ressource dans ce système REST. L'URI nous permet d'accéder aux informations afin de les modifier ou de les supprimer, ou par exemple de partager son emplacement exact avec des tiers.
- Interface uniforme : pour transférer des données, le système REST applique des actions spécifiques (POST, GET, PUT et DELETE) sur les ressources, à condition qu'ils soient identifiés par un URI. Cela facilite l'obtention d'une interface uniforme qui systématise le processus avec les informations.
- Système de couches : architecture hiérarchique entre les composants. Chaque couche a une fonctionnalité dans le système REST.
- Utilisation de l'hypermédia : hypermédia est un terme inventé par Ted Nelson en 1965 et est une extension du concept d'hypertexte. Ce concept, appliqué au développement de pages Web, est ce qui permet à l'utilisateur de parcourir l'ensemble d'objets via des liens HTML. Dans le cas d'une API REST, le concept d'hypermédia explique la capacité d'une interface de développement d'application à fournir au client et à l'utilisateur les liens adéquats pour exécuter des actions spécifiques sur les données.
Les avantages
- Séparation entre le client et le serveur : le protocole REST sépare totalement l'interface utilisateur du serveur et du stockage de données. Cela présente certains avantages lors des développements. Par exemple, il améliore la portabilité de l'interface vers d'autres types de plateformes, il augmente l'évolutivité des projets et permet aux différents composants des développements d'évoluer indépendamment.
- Visibilité, fiabilité et évolutivité . La séparation entre le client et le serveur présente un avantage évident, c'est que chaque équipe de développement peut faire évoluer le produit sans trop de problème. Ils peuvent migrer vers d'autres serveurs ou effectuer toutes sortes de modifications dans la base de données, à condition que les données de chaque demande soient envoyées correctement. La séparation permet d'avoir plus facilement l'avant et l'arrière sur différents serveurs, ce qui rend les applications plus flexibles avec lesquelles travailler.
- L'API REST est toujours indépendante du type de plateforme ou de langues : l'API REST s'adapte toujours à le type de syntaxe ou de plates-formes utilisées, ce qui donne une liberté considérable lors de la modification ou du test de nouveaux environnements dans le développement Avec une API REST, vous pouvez avoir des serveurs PHP, Java, Python ou Node.js. La seule chose est qu'il est indispensable que les réponses aux demandes aient toujours lieu dans la langue utilisée pour l'échange d'informations, normalement XML ou JSON.
Pourquoi pensez-vous que l'utilisation de POST et GET signifie que ce n'est pas REST?
Le point à REST est que chaque "ressource" a un identifiant de ressource, un URI. Chaque URI potentiellement a GET, POST, PUT, DELETE.
- GET est lu
- POST est à jour
- PUT c'est créer
- DELETE est supprimer
Si vous ne faites pas certaines de ces choses - comme PUT est assez rare et un trou de sécurité potentiel - alors vous ne le faites pas.
Vous devez utiliser REST car il englobe vraiment toutes les actions potentielles que vous souhaitez effectuer sur une ressource/un objet.
- GET - Récupérer une ressource en fonction de conditions données
- POST - créer une ressource
- PUT - mettre à jour une ressource avec les attributs mis à jour donnés
- DELETE - supprimer une ressource
Une autre raison est que c'est une norme que tout le monde peut mettre en œuvre et utiliser. Pour lire pourquoi la normalisation est importante, je suggère de lire this et this (c'est plutôt drôle, mais aide vraiment les gens à comprendre le concept de REST).