@John Saunders: Comment est-ce un doublon possible? L'autre type sait apparemment ce qu'est REST alors que Nathan, d'un autre côté, est confus.
Fake Code Monkey Rashid
J'ai senti que l'autre répondrait à sa question. Si personne d'autre n'est d'accord, alors le vote serré prendra fin. Nous avons une dizaine de réponses à cette question. Cliquez simplement sur la balise "reste" et vous les verrez toutes.
John Saunders
1
REST est un ensemble de règles pour la création de services Web. Si une API est construite selon ces règles, il s'agit d'une API REST. Comment j'ai expliqué REST à mon canard en caoutchouc explique certaines de ces règles de manière informelle.
User42
Réponses:
127
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.
@Nathan, fais-moi confiance, j'ai eu le même problème qu'avant. Lisez la thèse, relisez-la peut-être quelques fois lentement, mais vous comprendrez le concept, ce n'est en fait pas difficile du tout. Les gens ont juste tendance à mal l'expliquer.
Anders
Lorsque les développeurs essaient d'utiliser REST et essaient de le faire uniquement sur leur code (sans planifier l'ensemble du système avec REST à l'esprit), l'enfer vient :-)
karatedog
@Anders, considérant que REST est ce qu'il est, comment pouvez-vous comparer REST et services Web?
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.
Vous avez de la chance, car Rails est construit sur les principes REST et si vous utilisez les outils Rails, votre code sera RESTful. Cependant, il y a des codeurs qui ne comprennent pas vraiment REST, ils codent ce qu'ils veulent et à la fin, ils utilisent ce `` formatage d'URL '' parce que c'est à la mode.
karatedog
8
partout où / users a été utilisé dans cette réponse, ne devrait-il pas être / posts?
Mayuresh Srivastava
@MayureshSrivastava Observez que les exemples PUT ont: id et que les exemples POST n'ont pas: id. Google pour le reste de l'histoire. (POST: non sûr, non idempotent; PUT: non sûr, idempotent)
Ajeet Ganga
38
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.
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."
REST est une architecture basée sur des contraintes, SOAP est un protocole, ce sont des choses complètement différentes. Je n'aime pas quand les gens parlent de SOAP et REST dans le même concept, il n'est pas étonnant que les gens soient confus à ce sujet.
Anders
@Anders - Il a dit qu'il cherchait une API REST et pensait que c'était un moyen d'utiliser les services Web. Vous pouvez utiliser REST comme ça et en cette capacité il accomplit une grande partie de ce que SOAP accomplit. Il est également possible de parler du Web comme de la plus grande application RESTful au monde, mais cela n'explique pas vraiment pourquoi vous utiliseriez une API REST.
Mark le
Cela a en fait été mon principal problème, voir REST et SOAP dans le même concept. Il semble que les API ne soient que de conception RESTful.
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.
C'est peut-être juste moi, mais j'aime voir la réponse pertinente sur stackoverflow avec la citation appropriée. Faites-moi plaisir et supposez que wikipedia a fait caca. À quoi sert votre lien alors hmm? :)
Fake Code Monkey Rashid
1
@Hack Saw: Cela ne devrait-il pas figurer dans votre réponse?
Fake Code Monkey Rashid
Je viens de remarquer la fonction d'édition. :)
Hack Saw
1
@karatedog: REST peut être réalisé avec HTTP, mais cela pourrait être fait avec une variété de méthodes de transfert de données.
Hack Saw
1
C'est le protocole HTTP sur lequel vous écrivez, REST est une architecture.
Réponses:
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.
la source
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:
/postsSerait comment un utilisateur accèderait à TOUS les messages, pour l'affichage./posts/:idCe serait comment un utilisateur accéderait et afficherait un message individuel, récupéré en fonction de son identifiant unique./posts/newSerait 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.
la source
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édiasXML,JSONetRDF. 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 exempleGET,PUT,POST,DELETE.RESTest généralement utilisé plusHTTP, 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.
la source
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:
la source
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.
la source