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

J'étais sous l'hypothèse que REST était un service Web, mais il semble que je me trompe en pensant cela - alors, qu'est-ce que REST?

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

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 était la thèse de Roy Thomas Fielding (2000), «Architectural Styles and the Design of Network-based Software Architectures» ( disponible en ligne à l'Université de Californie, Irvine).

Lisez d'abord le post de Ryan Tomayko Comment j'ai expliqué REST à ma femme ; c'est un excellent point de départ. Ensuite, lisez la thèse de Fielding. Ce n'est pas si avancé, ni long (six chapitres, 180 pages)! (Je sais que vous les enfants à l'école aimez ça court).

EDIT: Je pense qu'il est inutile d'essayer d'expliquer REST. Il a tellement de concepts comme l'évolutivité, la visibilité (sans état), etc. que le lecteur doit saisir, et la meilleure source pour les comprendre est la thèse réelle. C'est bien plus que POST / GET etc.

REST est un modèle de conception de logiciel généralement utilisé pour les applications Web. En termes simples, cela signifie que c'est une idée couramment utilisée dans de nombreux projets différents. Il signifie REpresentational State Transfer . L'idée de base de REST est de traiter les objets côté serveur (comme dans les lignes d'une table de base de données) comme des ressources qui peuvent être créées ou détruites.

La manière la plus élémentaire de penser à REST est de mettre en forme les URL de vos applications Web. Par exemple, si votre ressource s'appelait "posts", alors:

/posts Serait comment un utilisateur accèderait à TOUS les messages, pour l'affichage.

/posts/:id Ce serait comment un utilisateur accéderait et afficherait un message individuel, récupéré en fonction de son identifiant unique.

/posts/new Serait la façon dont vous afficheriez un formulaire pour créer un nouveau message.

L' envoi d' une requête POST à /usersserait comment vous réellement créer un nouveau poste au niveau de la base de données.

Envoyer une demande PUT à /users/:idserait la façon dont vous mettriez à jour les attributs d'un message donné, à nouveau identifié par un identifiant unique.

Envoyer une demande DELETE à /users/:idserait la façon dont vous supprimeriez un message donné, à nouveau identifié par un identifiant unique.

Si je comprends bien, 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. Je pourrais me tromper cependant.

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

Quand quelqu'un fait référence à une "API REST", ce qu'ils veulent généralement dire est une API qui utilise des URL RESTful pour récupérer des données.

RESTest un style architectural et un design pour les architectures logicielles basées sur le réseau.

RESTles concepts sont appelés ressources. Une représentation d'une ressource doit être sans état. Il est représenté via un type de média. Comprennent quelques exemples de types de médias XML, JSONet RDF. Les ressources sont manipulées par des composants. Les composants demandent et manipulent les ressources via une interface uniforme standard. Dans le cas de HTTP, cette interface se compose d'opérations HTTP standard par exemple GET, PUT, POST, DELETE.

RESTest généralement utilisé plus HTTP, principalement en raison de la simplicité de HTTP et de son mappage très naturel aux principes RESTful. REST n'est cependant lié à aucun protocole spécifique.

Principes fondamentaux de REST

Communication client-serveur

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

Apatride

Chaque demande client adressée 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 de contexte de serveur ou d'état de session du serveur. Il s'ensuit que tous les états doivent être conservés sur le client. Nous aborderons plus en détail la représentation sans état plus tard.

Cacheable

Des contraintes de 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 mises en cache. Toutes les données marquées comme pouvant être mises en cache peuvent être réutilisées comme réponse à la même demande ultérieure.

Interface uniforme

Tous les composants doivent interagir via une seule interface uniforme. Étant donné que toutes les interactions des composants se produisent via cette interface, l'interaction avec différents services est très simple. L'interface est la même! Cela signifie également que les modifications d'implémentation peuvent être effectuées de manière isolée. De tels changements n'affecteront pas l'interaction fondamentale des composants car l'interface uniforme est toujours inchangée. Un inconvénient est que vous êtes coincé avec l'interface. Si une optimisation pouvait être fournie à un service spécifique en modifiant l'interface, vous n'avez pas de chance car REST l'interdit. Du côté positif, cependant, 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 des autres architectures telles que 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 post sur Principals REST conception pour plus de détails sur REST et les principes ci - dessus.

Cela signifie Representational State Transfer et cela peut signifier beaucoup de choses, mais généralement, lorsque vous parlez d'API et d'applications, vous parlez de REST comme un moyen de créer des services Web ou de faire parler des programmes sur le Web.

REST est fondamentalement un moyen de communication entre les 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, authentifie et fait des choses sur cette connexion, REST fonctionne à peu près de la même manière que le Web fonctionne. . Vous avez une URL et lorsque vous demandez cette URL, vous obtenez quelque chose en retour. C'est là que les choses commencent à devenir confuses, 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 un mot, REST vous permet de faire parler deux applications sur 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."

A lire:

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

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

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