Apparemment, REST n'est qu'un ensemble de conventions sur la façon d'utiliser HTTP . Je me demande quel avantage ces conventions offrent. Est-ce que quelqu'un sait?

Je ne pense pas que vous obtiendrez une bonne réponse à cette question , en partie parce que personne n'accepte vraiment de ce que REST est . La page wikipedia est riche en mots à la mode et légère en explications. La page de discussion vaut la peine d'être parcourue juste pour voir à quel point les gens ne sont pas d'accord à ce sujet. Autant que je sache cependant, REST signifie ceci:

Au lieu d'avoir des URL setter et getter nommé de façon aléatoire et en utilisant GETpour tous les getters et POSTpour tous les setters, nous essayons d'avoir les URL identifier les ressources, puis utiliser les actions HTTP GET, POST, PUTet DELETEde faire des choses pour eux. Donc au lieu de

GET /get_article?id=1
POST /delete_article   id=1

Vous feriez

GET /articles/1/
DELETE /articles/1/

Et puis POSTet PUTcorrespondent aux opérations de «création» et de «mise à jour» (mais personne n'est d'accord dans quel sens).

Je pense que les arguments de mise en cache sont faux, car les chaînes de requête sont généralement mises en cache, et en plus vous n'avez pas vraiment besoin de les utiliser. Par exemple, django rend quelque chose comme ça très facile, et je ne dirais pas que c'était REST:

GET /get_article/1/
POST /delete_article/     id=1

Ou même simplement inclure le verbe dans l'URL:

GET /read/article/1/
POST /delete/article/1/
POST /update/article/1/
POST /create/article/

Dans ce cas, cela GETsignifie quelque chose sans effets secondaires, et POSTsignifie quelque chose qui change les données sur le serveur. Je pense que c'est peut-être un peu plus clair et plus facile, d'autant plus que vous pouvez éviter le tout PUT-vs- POST. De plus, vous pouvez ajouter plus de verbes si vous le souhaitez, de sorte que vous n'êtes pas lié artificiellement à ce que propose HTTP. Par exemple:

POST /hide/article/1/
POST /show/article/1/

(Ou peu importe, il est difficile de penser à des exemples jusqu'à ce qu'ils se produisent!)

Donc en conclusion, il n'y a que deux avantages que je peux voir:

1. Votre API Web peut être plus propre et plus facile à comprendre / découvrir.
2. Lors de la synchronisation des données avec un site Web, il est probablement plus facile d'utiliser REST car vous pouvez simplement dire synchronize("/articles/1/")ou quoi que ce soit. Cela dépend fortement de votre code.

Cependant, je pense qu'il y a de gros inconvénients:

1. Toutes les actions ne sont pas facilement mappées sur CRUD (créer, lire / récupérer, mettre à jour, supprimer). Vous n'avez peut-être même pas affaire à des ressources de type objet.
2. C'est un effort supplémentaire pour des avantages douteux.
3. Confusion quant à quel chemin PUTet POSTsont. En anglais, ils signifient des choses similaires ("Je vais mettre / poster un avis sur le mur.").

Donc, en conclusion, je dirais: à moins que vous ne souhaitiez vraiment faire un effort supplémentaire, ou si votre service correspond vraiment bien aux opérations CRUD, enregistrez REST pour la deuxième version de votre API.

Je viens de rencontrer un autre problème avec REST: il n'est pas facile de faire plus d'une chose dans une seule demande ou de spécifier les parties d'un objet composé que vous souhaitez obtenir. Ceci est particulièrement important sur les mobiles où le temps d'aller-retour peut être important et les connexions ne sont pas fiables. Par exemple, supposons que vous recevez des messages sur une chronologie Facebook. La méthode REST "pure" serait quelque chose comme

GET /timeline_posts     // Returns a list of post IDs.
GET /timeline_posts/1/  // Returns a list of message IDs in the post.
GET /timeline_posts/2/
GET /timeline_posts/3/
GET /message/10/
GET /message/11/
....

Ce qui est un peu ridicule. L'API de Facebook est très bonne IMO, alors voyons ce qu'ils font:

Par défaut, la plupart des propriétés d'objet sont renvoyées lorsque vous effectuez une requête. Vous pouvez choisir les champs (ou connexions) que vous souhaitez renvoyer avec le paramètre de requête "champs". Par exemple, cette URL ne renverra que l'identifiant, le nom et l'image de Ben: https://graph.facebook.com/bgolub?fields=id,name,picture

Je ne sais pas comment vous feriez quelque chose comme ça avec REST, et si vous le faisiez, cela compterait toujours comme REST. J'ignorerais certainement quiconque essaie de vous dire que vous ne devriez pas faire ça (surtout si la raison est "parce que ce n'est pas REST")!

En termes simples, REST signifie utiliser HTTP comme il se doit.

Jetez un œil à la thèse de Roy Fielding sur REST . Je pense que chaque personne qui fait du développement Web devrait le lire.

À noter, Roy Fielding est également l'un des principaux moteurs du protocole HTTP.

Pour citer quelques-uns des avantages:

• Facile.
• Vous pouvez faire bon usage du cache HTTP et du serveur proxy pour vous aider à gérer une charge élevée.
• Il vous aide à organiser même une application très complexe en ressources simples.
• Cela permet aux nouveaux clients d'utiliser facilement votre application, même si vous ne l'avez pas conçue spécifiquement pour eux (probablement, car ils n'étaient pas là lorsque vous avez créé votre application).

En termes simples: AUCUN .

N'hésitez pas à voter contre, mais je pense toujours qu'il n'y a pas de réels avantages par rapport au HTTP non REST. Toutes les réponses actuelles sont invalides. Arguments de la réponse actuellement la plus votée:

• Facile.
• Vous pouvez faire bon usage du cache HTTP et du serveur proxy pour vous aider à gérer une charge élevée.
• Il vous aide à organiser même une application très complexe en ressources simples.
• Cela permet aux nouveaux clients d'utiliser facilement votre application, même si vous ne l'avez pas conçue spécifiquement pour eux (probablement, car ils n'étaient pas là lorsque vous avez créé votre application).

1. Simple

Avec REST, vous avez besoin d'une couche de communication supplémentaire pour vos scripts côté serveur et côté client => c'est en fait plus compliqué que l'utilisation de HTTP non REST.

2. Mise en cache

La mise en cache peut être contrôlée par des en-têtes HTTP envoyés par le serveur. REST n'ajoute aucune fonctionnalité manquante dans non-REST.

3. Organisation

REST ne vous aide pas à organiser les choses. Cela vous oblige à utiliser l'API prise en charge par la bibliothèque côté serveur que vous utilisez. Vous pouvez organiser votre application de la même manière (ou mieux) lorsque vous utilisez une approche non REST. Par exemple, voir Model-View-Controller ou routage MVC .

4. Facile à utiliser / mettre en œuvre

Pas vrai du tout. Tout dépend de la manière dont vous organisez et documentez votre candidature. REST n'améliorera pas comme par magie votre application.

À mon humble avis, le plus grand avantage de REST est celui de réduire le couplage client / serveur. Il est beaucoup plus facile de faire évoluer une interface REST au fil du temps sans casser les clients existants.

Découvrabilité

Chaque ressource a des références à d'autres ressources, que ce soit dans la hiérarchie ou les liens, il est donc facile de naviguer. C'est un avantage pour l'humain qui développe le client, lui évite de consulter constamment la documentation et de proposer des suggestions. Cela signifie également que le serveur peut changer unilatéralement les noms de ressources (tant que le logiciel client ne code pas en dur les URL).

Compatibilité avec d'autres outils

Vous pouvez CURL votre chemin dans n'importe quelle partie de l'API ou utiliser le navigateur Web pour naviguer dans les ressources. Rend le débogage et le test de l'intégration beaucoup plus faciles.

Noms de verbes normalisés

Vous permet de spécifier des actions sans avoir à rechercher la formulation correcte. Imaginez si getters POO et setters ne sont pas standardisés, et certaines personnes ont utilisé retrieveet à la defineplace. Vous devrez mémoriser le verbe correct pour chaque point d'accès individuel. Sachant qu'il n'y a qu'une poignée de verbes disponibles, ce problème est résolu.

Statut normalisé

Si vous avez GETune ressource qui n'existe pas, vous pouvez être sûr d'obtenir une 404erreur dans une API RESTful. Comparez-le avec une API non RESTful, qui peut retourner {error: "Not found"}enveloppée dans Dieu sait combien de couches. Si vous avez besoin d'espace supplémentaire pour écrire un message au développeur de l'autre côté, vous pouvez toujours utiliser le corps de la réponse.

Exemple

Imaginez deux API avec la même fonctionnalité, l'une suivant REST et l'autre non. Imaginez maintenant les clients suivants pour ces API:

Reposant:

GET /products/1052/reviews
POST /products/1052/reviews       "5 stars"
DELETE /products/1052/reviews/10
GET /products/1052/reviews/10

HTTP:

GET /reviews?product_id=1052
POST /post_review?product_id=1052                  "5 stars"
POST /remove_review?product_id=1052&review_id=10
GET /reviews?product_id=1052&review=10

Pensez maintenant aux questions suivantes:

• Si le premier appel de chaque client a fonctionné, comment pouvez-vous être sûr que le reste fonctionnera également?

• Il y a eu une mise à jour majeure de l'API qui peut ou non avoir changé ces points d'accès. Combien de documents devrez-vous relire?

• Pouvez-vous prédire le retour de la dernière requête?

• Vous devez modifier l'avis publié (avant de le supprimer). Pouvez-vous le faire sans consulter les documents?

Je recommande de jeter un œil à Comment j'ai expliqué REST à ma femme de Ryan Tomayko

Modification tierce

Extrait du lien waybackmaschine:

Que diriez-vous d'un exemple. Vous êtes enseignant et souhaitez gérer des élèves:

• dans quelles classes ils sont,
• quelles notes ils obtiennent,
• contacts d'urgence,
• des informations sur les livres que vous enseignez, etc.

Si les systèmes sont basés sur le Web, alors il y a probablement une URL pour chacun des noms impliqués ici: student, teacher, class, book, room, etc. ... S'il y avait une représentation lisible par machine pour chaque URL, alors il serait trivial de verrouiller de nouveaux outils sur le système car toutes ces informations seraient consommables de manière standard. ... vous pourriez créer un système à l'échelle du pays capable de parler à chacun des systèmes scolaires individuels pour recueillir les résultats des tests.

Chacun des systèmes obtiendrait des informations les uns des autres en utilisant un simple HTTP GET. Si un système a besoin d'ajouter quelque chose à un autre système, il utilise un HTTP POST. Si un système souhaite mettre à jour quelque chose dans un autre système, il utilise un HTTP PUT. Il ne reste plus qu'à savoir à quoi devraient ressembler les données.

Je suggère à tout le monde, qui cherche une réponse à cette question, de passer par ce "diaporama" .

Je ne pouvais pas comprendre ce qu'est REST et pourquoi il est si cool, ses avantages et ses inconvénients, ses différences avec SOAP - mais ce diaporama était si brillant et facile à comprendre, donc il est beaucoup plus clair pour moi maintenant qu'avant.

Mise en cache.

Il existe d'autres avantages plus détaillés de REST qui tournent autour de la capacité d'évolution via un couplage lâche et l'hypertexte, mais les mécanismes de mise en cache sont la principale raison pour laquelle vous devriez vous soucier de RESTful HTTP.

C'est écrit dans la thèse de Fielding . Mais si vous ne voulez pas beaucoup lire:

• une évolutivité accrue (en raison des contraintes du système sans état, de cache et en couches)
• client et serveur découplés (en raison de contraintes d'interface sans état et uniformes)
  • clients réutilisables (le client peut utiliser les navigateurs REST généraux et la sémantique RDF pour décider quel lien suivre et comment afficher les résultats)
  • clients non cassants (les clients ne cassent que par des changements de sémantique spécifiques à l'application, car ils utilisent la sémantique au lieu de certaines connaissances spécifiques à l'API)

• Donnez à chaque «ressource» un identifiant
• Liez les choses ensemble
• Utilisez des méthodes standard
• Ressources avec plusieurs représentations
• Communiquer de manière apatride

Est-il possible de tout faire simplement avec POST et GET? Oui, est-ce la meilleure approche? Non pourquoi? parce que nous avons des méthodes standards. Si vous réfléchissez encore, il serait possible de tout faire en utilisant simplement GET .. alors pourquoi devrions-nous même prendre la peine d'utiliser POST? À cause des normes!

Par exemple, en pensant aujourd'hui à un modèle MVC, vous pouvez limiter votre application pour qu'elle ne réponde qu'à des types spécifiques de verbes tels que POST, GET, PUT et DELETE. Même si sous le capot, tout est émulé pour POST et GET, cela n'a pas de sens d'avoir des verbes différents pour différentes actions?

La découverte est beaucoup plus facile dans REST. Nous avons des documents WADL (similaires à WSDL dans les services Web traditionnels) qui vous aideront à faire connaître votre service dans le monde. Vous pouvez également utiliser les découvertes UDDI. Avec HTTP POST et GET, les personnes peuvent ne pas connaître vos schémas de demande de message et de réponse pour vous appeler.

Un avantage est que nous pouvons traiter de manière non séquentielle des documents XML et des données XML démarsales provenant de différentes sources comme un objet InputStream, une URL, un nœud DOM ...

@Timmmm, à propos de votre modification:

GET /timeline_posts     // could return the N first posts, with links to fetch the next/previous N posts

Cela réduirait considérablement le nombre d'appels

Et rien ne vous empêche de concevoir un serveur qui accepte les paramètres HTTP pour désigner les valeurs de champ souhaitées par vos clients ...

Mais c'est un détail.

Beaucoup plus important est le fait que vous n'avez pas mentionné d'énormes avantages du style architectural REST (bien meilleure évolutivité, en raison de l'apatridie du serveur; bien meilleure disponibilité, en raison de l'apatridie du serveur également; une bien meilleure utilisation des services standard, tels que la mise en cache pour exemple, lors de l'utilisation d'un style architectural REST; couplage beaucoup plus faible entre le client et le serveur, en raison de l'utilisation d'une interface uniforme; etc. etc.)

Quant à votre remarque

"Toutes les actions ne sont pas facilement mappées à CRUD (créer, lire / récupérer, mettre à jour, supprimer)."

: un SGBDR utilise également une approche CRUD (SELECT / INSERT / DELETE / UPDATE), et il existe toujours un moyen de représenter et d'agir sur un modèle de données.

Concernant votre peine

"Vous n'avez peut-être même pas affaire à des ressources de type objet"

: une conception RESTful est, par essence, une conception simple - mais cela ne signifie PAS que sa conception est simple. Voyez-vous la différence ? Vous devrez beaucoup réfléchir aux concepts que votre application représentera et traitera, à ce qui doit être fait par elle, si vous préférez, afin de la représenter au moyen de ressources. Mais si vous le faites, vous vous retrouverez avec une conception plus simple et plus efficace.

Les chaînes de requête peuvent être ignorées par les moteurs de recherche.