Quel est l’avantage d’utiliser reste au lieu de non HTTP REST ?

Question

Apparemment, que reste est juste un ensemble de conventions sur la façon d’utiliser le protocole HTTP. Je me demande quel avantage ces conventions fournissent. Est-ce que quelqu'un sait ?

Answer 1

Je ne pense pas que vous obtiendrez une bonne réponse à cette question, en partie parce que personne n'est d'accord sur ce qui RESTE est. La page wikipedia est lourd sur les mots à la mode et de la lumière sur l'explication. La page de discussion vaut écrémé juste pour voir combien de personnes sont en désaccord sur ce point. Aussi loin que je peux dire, cependant, RESTE signifie ceci:

Au lieu d'avoir nommé de façon aléatoire setter et getter Url et à l'aide de GET pour tous les getters et POST pour tous les opérateurs, nous essayons d'avoir l'Url d'identifier les ressources, et ensuite utiliser le HTTP actions GET, POST, PUT et DELETE à faire des choses pour eux. Ainsi, au lieu de

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

Vous feriez

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

Et puis, POST et PUT correspondent à "créer" et "mise à jour" (mais personne n'est d'accord qui tour).

Je pense que la mise en cache des arguments sont faux, parce que les chaînes de requête sont généralement mis en cache, et d'ailleurs vous n'avez pas vraiment besoin de les utiliser. Par exemple django fait quelque chose comme ça très facile, et je ne dirais pas que c'était le REPOS:

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

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

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

Dans ce cas GET signifie quelque chose, sans effets secondaires, et POST signifie quelque chose que les modifications des données sur le serveur. Je pense que c'est peut-être un peu plus clair et plus facile, surtout que vous pouvez éviter de l'ensemble de l' PUT-vs-POST chose. De Plus, vous pouvez ajouter plus de verbes si vous voulez, de sorte que vous ne sont pas artificiellement à ce HTTP offre. Par exemple:

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

(Ou que ce soit, il est difficile de penser à des exemples jusqu'à ce qu'ils arrivent!)

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

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

Cependant, je pense qu'il y a un peu assez des inconvénients:

1. Pas toutes les actions facilement la carte de CRUD (create, read/retrieve, update, delete). On ne peut même pas avoir affaire à un objet de type de ressources.
2. C'est un effort supplémentaire pour douteux avantages.
3. Toute Confusion sur le chemin de ronde, PUT et POST . En anglais ils dire la même chose ("je vais mettre/poster un avis sur le mur.").

Donc, en conclusion, je dirais: si vous voulez vraiment aller de l'effort supplémentaire, ou si votre service des cartes vraiment bien pour les opérations CRUD, enregistrer de REPOS pour la deuxième version de votre API.

Modifier

Je viens de tomber sur un autre problème avec le REPOS: Il n'est pas facile de faire plus d'une chose à une demande ou de spécifier les parties d'un composé de l'objet que vous souhaitez obtenir. Ceci est particulièrement important sur mobile où aller-retour-l'heure peuvent être importantes et les connexions ne sont pas fiables. Par exemple, supposons que vous obtenez des messages sur facebook timeline. La "pure" RESTE 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 ridicule. Facebook API est assez grande de l'OMI, afin de laisser voir ce qu'ils font:

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

Je n'ai aucune idée comment vous feriez quelque chose comme ça avec le RESTE, et si vous n'avez que ce serait encore le comte de REPOS. Je serais certainement ignorer toute personne qui tente de vous dire que vous ne devriez pas le faire si (surtout si la raison: "parce qu'il n'est pas de REPOS")!

Answer 2

Il suffit de mettre, RESTE moyen à l'aide de HTTP de la façon dont il est censé être.

Jetez un oeil à Roy Fielding de la thèse sur le REPOS. Je pense que chaque personne qui est en train de faire du développement web devraient le lire.

Comme une note, Roy Fielding est l'un des facteurs clés à l'origine du protocole HTTP.

Nom de advandages:

• Simple.
• Vous pouvez faire bon usage de cache HTTP et serveur proxy pour vous aider à gérer la charge élevée.
• Cela vous aide à organiser même très complexe de l'application de simples ressources.
• Il le rend facile pour les nouveaux clients pour l'utilisation de votre application, même si vous n'avez pas conçu spécifiquement pour eux (probablement, parce qu'ils n'étaient pas là lors de la création de votre application).

Answer 3

Il suffit de mettre: AUCUN.

Hésitez pas à downvote, mais je pense toujours qu'il n'y a pas de réels avantages par rapport aux non-REPOS HTTP. Toutes les réponses ne sont pas valides. Les Arguments de la actuellement plus de vote réponse:

• Simple.
• Vous pouvez faire bon usage de cache HTTP et serveur proxy pour vous aider à gérer la charge élevée.
• Cela vous aide à organiser même très complexe de l'application de simples ressources.
• Il le rend facile pour les nouveaux clients pour l'utilisation de votre application, même si vous n'avez pas conçu spécifiquement pour eux (probablement, parce qu'ils n'étaient pas là lors de la création de votre application).

1. Simple

Avec le RESTE vous avez besoin d'une couche de communication de votre côté serveur et côté client scripts => c'est en fait plus compliqué que l'utilisation de la non-REPOS HTTP.

2. La mise en cache

La mise en cache peut être contrôlé par les en-têtes HTTP envoyés par le serveur. RESTE à ne pas ajouter de fonctionnalités manquantes dans le non-REPOS.

3. Organisation

RESTE à ne pas aider à vous organiser les choses. C' forces vous à utilisation de l'API supportées par le serveur-côté de la bibliothèque que vous utilisez. Vous pouvez organiser votre application de la même façon (ou plus) lorsque vous utilisez le non-REPOS approche. E. g. voir le Modèle-Vue-Contrôleur ou MVC de routage.

4. Facile à utiliser/mettre en œuvre

Pas vrai du tout. Tout dépend de comment bien vous organiser et documenter votre demande. Le REPOS ne sera pas magiquement améliorer votre demande.

Answer 4

AMHA, le plus grand avantage qui reste active est celle de réduire le couplage de client/serveur. Il est plus facile d’évoluer une interface REST au fil du temps, sans interrompre les clients existants.

Answer 5

Je vous recommande de prendre un coup d’oeil à Ryan Tomayko Comment j’ai expliqué REST à ma femme