Qu'est-ce que REST ? Légèrement confus

Question

Je pensais que REST était un service web, mais il semble que j'aie tort - alors, qu'est-ce que REST ?

J'ai lu Wikipédia mais je n'arrive toujours pas à m'y retrouver. Pourquoi de nombreux endroits font-ils référence aux API en tant qu'API REST ?

Answer 1

REST n'est pas un service web spécifique mais un concept de conception (architecture) pour la gestion des informations d'état. L'article fondateur à ce sujet est la thèse de Roy Thomas Fielding (2000), "Architectural Styles and the Design of Network-based Software Architectures" ( disponible en ligne de l'Université de Californie, Irvine).

Lisez d'abord le message de Ryan Tomayko Comment j'ai expliqué REST à ma femme c'est un excellent point de départ. Lisez ensuite la dissertation de Fielding. Elle n'est pas si avancée, et elle n'est pas longue (six chapitres, 180 pages) ! (Je sais que vous, les jeunes de l'école, aimez les textes courts).

EDIT : Je pense qu'il est inutile d'essayer d'expliquer REST. Il y a tellement de concepts comme l'extensibilité, la visibilité (stateless) etc. que le lecteur doit saisir, et la meilleure source pour les comprendre est la dissertation actuelle. C'est bien plus que POST/GET etc.

Answer 2

REST est un modèle de conception logicielle généralement utilisé pour les applications web. En termes simples, cela signifie qu'il s'agit d'une idée courante utilisée dans de nombreux projets différents. L'acronyme REST signifie Transfert d'état de représentation (REpresentational State Transfer) . L'idée de base de REST est de traiter les objets du côté serveur (comme les lignes d'une table de base de données) comme des ressources qui peuvent être créées ou détruites.

La façon la plus élémentaire d'envisager REST est de formater les URL de vos applications web. Par exemple, si votre ressource s'appelle "posts", alors :

/posts Ce serait la façon dont un utilisateur pourrait accéder à TOUS les messages, pour les afficher.

/posts/:id Il s'agit de la façon dont un utilisateur peut accéder à un message individuel et le visualiser, en fonction de son identifiant unique.

/posts/new Il s'agit de la façon dont vous affichez un formulaire pour créer un nouveau message.

Envoi d'une demande POST à /users serait de savoir comment vous allez créer un nouveau poste au niveau de la base de données.

Envoi d'une demande PUT à /users/:id permet de mettre à jour les attributs d'un message donné, identifié lui aussi par un identifiant unique.

Envoi d'une demande DELETE à /users/:id serait la façon de supprimer un message donné, encore une fois identifié par un identifiant unique.

D'après ce que j'ai compris, le modèle REST a été principalement popularisé (pour les applications Web) par le framework Ruby on Rails, qui met l'accent sur les routes RESTful. Mais je peux me tromper.

Je ne suis peut-être pas le plus qualifié pour en parler, mais c'est ainsi que je l'ai appris (spécifiquement pour le développement de Rails).

Lorsque quelqu'un fait référence à une "api REST", il s'agit généralement d'une api qui utilise des urls RESTful pour récupérer des données.

Answer 3

REST es un style architectural et un design pour les architectures logicielles en réseau.

REST Les concepts sont appelés ressources. La représentation d'une ressource doit être sans état. Elle est représentée par un certain type de média. Voici quelques exemples de types de médias XML , JSON et RDF . Les ressources sont manipulées par les composants. Les composants demandent et manipulent les ressources via une interface standard uniforme. Dans le cas de HTTP, cette interface est constituée d'opérations HTTP standard, par ex. GET , PUT , POST , DELETE .

REST est généralement utilisé sur HTTP L'utilisation de la technologie RESTful, principalement en raison de la simplicité du protocole HTTP et de sa correspondance très naturelle avec les principes RESTful. REST n'est toutefois pas lié à un protocole spécifique.

Principes fondamentaux de REST

Communication client-serveur

Les architectures client-serveur présentent une séparation très nette des préoccupations. Toutes les applications construites dans le style RESTful doivent également être client-serveur en principe.

Apatride

Chaque demande du client au serveur nécessite que son état soit entièrement représenté. Le serveur doit être capable de comprendre complètement la demande du client sans utiliser le contexte du serveur ou l'état de la session du serveur. Il s'ensuit que tout l'état doit être conservé sur le client. Nous aborderons la représentation sans état plus en détail ultérieurement.

Cachable

Des contraintes de mise en cache peuvent être utilisées, permettant ainsi aux données de réponse d'être marquées comme pouvant être mises en cache ou non. Toute donnée marquée comme pouvant être mise en cache peut être réutilisée comme réponse à la même demande ultérieure.

Interface uniforme

Tous les composants doivent interagir par le biais d'une seule interface uniforme. Comme toutes les interactions entre composants se font via cette interface, l'interaction avec différents services est très simple. L'interface est la même ! Cela signifie également que les changements d'implémentation peuvent être effectués de manière isolée. De tels changements n'affecteront pas l'interaction fondamentale des composants car l'interface uniforme reste toujours inchangée. L'inconvénient, c'est que vous êtes coincé avec l'interface. Si un service spécifique pouvait être optimisé en modifiant l'interface, vous n'avez pas de chance car REST l'interdit. Le bon côté des choses, c'est que REST est optimisé pour le web, d'où l'incroyable popularité de REST sur HTTP !

Les concepts ci-dessus représentent les caractéristiques de définition de REST et différencient l'architecture REST d'autres architectures comme les services web. Il est utile de noter qu'un service REST est un service web, mais qu'un service web n'est pas nécessairement un service REST.

Voir ce blog poste sur Principes de conception REST pour plus de détails sur REST et les principes ci-dessus.

Answer 4

Il s'agit de l'abréviation de "Representational State Transfer", qui peut signifier beaucoup de choses, mais généralement, lorsque l'on parle d'API et d'applications, on parle de REST comme d'un moyen de créer des services Web ou de faire en sorte que les programmes communiquent sur le Web.

REST est essentiellement un moyen de communiquer entre systèmes et fait une grande partie de ce que SOAP RPC a été conçu pour faire, mais alors que SOAP établit généralement une connexion, s'authentifie et fait ensuite des choses sur cette connexion, REST fonctionne à peu près de la même manière que le web. Vous avez une URL et lorsque vous demandez cette URL, vous recevez quelque chose en retour. C'est là que les choses commencent à s'embrouiller, car les gens décrivent le web comme la plus grande application REST et, bien que cela soit techniquement correct, cela n'aide pas vraiment à expliquer ce que c'est.

En résumé, REST permet de faire dialoguer deux applications sur l'internet à l'aide d'outils similaires à ceux utilisés par un navigateur web. C'est beaucoup plus simple que SOAP et une grande partie de ce que fait REST est de dire "Hé, les choses ne doivent pas être si complexes".

Cela vaut la peine de lire :

• Comment j'ai expliqué REST à ma femme (maintenant disponible ici)
• Styles architecturaux et conception d'architectures logicielles en réseau

Answer 5

http://en.wikipedia.org/wiki/Representational_State_Transfer

L'idée de base est qu'au lieu d'avoir une connexion permanente avec le serveur, vous faites une demande, obtenez certaines données, les montrez à l'utilisateur, mais peut-être pas toutes, et ensuite, lorsque l'utilisateur fait quelque chose qui demande plus de données, ou en transmet au serveur, le client initie un changement vers un nouvel état.