Quelle est la différence entre les protocoles REST et HTTP?
Quel est le protocole REST et en quoi diffère-t-il du protocole HTTP ?
5 réponses
REST est une approche qui tire parti du protocole HTTP, et n'est pas une alternative à celui-ci.
Les données sont référencées de manière unique par URL et peuvent être utilisées à l'aide D'opérations HTTP (GET, PUT, POST, DELETE, etc.). Une grande variété de types mime sont pris en charge pour le message/réponse, mais XML et JSON sont les plus courants.
Par exemple Pour lire des données sur un client vous pouvez utiliser un HTTP get opération avec L'URL http://www.example.com/customers/1 . Si vous souhaitez supprimer ce client, utilisez simplement L'opération de suppression HTTP avec la même URL.
Le code Java CI-DESSOUS montre comment faire un appel REST sur le protocole HTTP:
String uri =
"http://www.example.com/customers/1";
URL url = new URL(uri);
HttpURLConnection connection =
(HttpURLConnection) url.openConnection();
connection.setRequestMethod("GET");
connection.setRequestProperty("Accept", "application/xml");
JAXBContext jc = JAXBContext.newInstance(Customer.class);
InputStream xml = connection.getInputStream();
Customer customer =
(Customer) jc.createUnmarshaller().unmarshal(xml);
connection.disconnect();
Pour un exemple Java (JAX-RS), voir:
REST est un style de conception pour les protocoles, il a été développé par Roy Fielding dans sa thèse de doctorat et formalisé L'approche derrière HTTP/1.0, trouver ce qui a bien fonctionné avec elle, puis en utilisant cette compréhension plus structurée de celui-ci pour influencer la conception de HTTP/1.1. Ainsi, alors que c'était après-le-fait à bien des égards, REST est le style de conception derrière HTTP.
La thèse de Fielding peut être trouvée à http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm et est beaucoup vaut la peine d'être lu, et aussi très lisible. Les thèses de doctorat peuvent être assez difficiles, mais celle-ci est merveilleusement bien décrite et très lisible pour ceux d'entre nous sans un niveau comparable de L'Informatique. Cela aide que le repos lui-même soit assez simple; c'est une de ces choses qui sont évidentes après que quelqu'un d'autre l'ait inventé. (Il encapsule également beaucoup de choses que les développeurs web plus anciens ont appris à la dure dans un style simple, ce qui en a fait un "a" majeur ha!"moment pour beaucoup).
D'autres protocoles au niveau de L'application ainsi que HTTP peuvent également utiliser REST, mais HTTP est l'exemple classique.
Comme HTTP utilise REST, toutes les utilisations de HTTP utilisent un système REST. La description D'une application ou d'un service web comme RESTful ou non-RESTful se rapporte à savoir si elle profite de REST ou fonctionne contre elle.
L'exemple classique d'un système RESTful est un site web "Simple" Sans cookies (les cookies ne sont pas toujours contraires à REST, mais ils peuvent be): L'état du Client est modifié par l'utilisateur en cliquant sur un lien qui charge une autre page, ou en faisant des requêtes GET form qui apportent des résultats. Les requêtes POST form peuvent changer l'état du serveur et du client (le serveur fait quelque chose sur la base du POST, puis envoie un document hypertexte qui décrit le nouvel état). Les URI décrivent les ressources, mais l'entité (document) qui les décrit peut différer selon le type de contenu ou la langue préférée par l'utilisateur. Enfin, il a toujours été possible pour les navigateurs de mettez à jour la page elle-même à travers PUT et DELETE bien que cela n'ait jamais été très commun et si quelque chose l'est moins maintenant.
L'exemple classique d'un système non RESTful utilisant HTTP est quelque chose qui traite HTTP comme s'il s'agissait d'un protocole de transport, et à chaque requête envoie un POST de données au même URI qui est ensuite agi de manière RPC, éventuellement avec la connexion elle-même ayant un état partagé.
Un RESTful lisible par ordinateur (c'est-à-dire pas un site Web dans un navigateur, mais quelque chose utilisé par programme) système obtiendrait des informations sur les ressources concernées en obtenant URI qui retournerait ensuite un document (par exemple en XML, mais pas nécessairement) qui décrirait l'état de la ressource, y compris les URI aux ressources connexes (hypermedia donc), changer leur état en mettant des entités décrivant le nouvel état ou les supprimer, et avoir d'autres actions effectuées
Les principaux avantages sont:
Évolutivité: le manque de partage l'État fait un système beaucoup plus évolutif (démontré massivement quand j'ai supprimé toute utilisation de l'état de session d'un site web fortement frappé, alors que je m'attendais à ce qu'il donne un peu de performance supplémentaire,même un défenseur anti-session de longue date comme moi a été époustouflé par le gain massif de supprimer ce qui avait été)
Simplicité: il existe différentes façons dont REST est plus simple que d'autres modèles de type RPC, en particulier, il n'y a que quelques "verbes" qui sont toujours possibles, et chaque type de ressource peut être raisonnée dans un isolement raisonnable par rapport aux autres.
Entités légères: plus de modèles de type RPC ont tendance à se retrouver avec beaucoup de données dans les entités envoyées dans les deux sens juste pour refléter le modèle de type RPC. Ce n'est pas nécessaire. En effet, parfois un simple document en texte brut est tout ce qui est vraiment nécessaire dans un cas donné, auquel cas avec REST, c'est tout ce que nous aurions besoin d'envoyer (bien que cela être un cas "résultat final" seulement, puisque le texte brut ne lie pas aux ressources connexes). Un autre exemple classique est une demande pour obtenir un fichier image, les modèles de type RPC doivent généralement l'envelopper dans un autre format, et peut-être l'encoder d'une manière ou d'une autre pour le laisser reposer dans le format parent (par exemple, si le modèle de type RPC utilise XML, l'image devra être basée sur 64 ou similaire Un modèle RESTful transmettrait simplement le fichier de la même manière qu'il le fait à un navigateur.
Lisible Par L'Homme Résultats: pas nécessairement, mais il est souvent facile de construire un webservice RESTful où les résultats sont relativement faciles à lire, ce qui facilite le débogage et le développement sans fin. J'en ai même construit un où un XSLT signifiait que tout pouvait être utilisé par les humains comme un site web (relativement brut), bien que ce ne soit pas principalement à usage humain (essentiellement, le XSLT servait de client pour le présenter aux utilisateurs, ce n'était même pas dans la spécification, juste fait pour faciliter mon propre développement!).
Liaison plus lâche entre le serveur et le client: conduit à un développement ultérieur plus facile ou se déplace dans la façon dont le système est hébergé. En effet, si vous vous en tenez au modèle hypertexte, vous pouvez modifier toute la structure, y compris passer d'un hôte unique à plusieurs hôtes pour différents services, sans changer du tout le code client.
Mise en cache: pour les opérations GET où le client obtient des informations sur l'état d'une ressource, les mécanismes de mise en cache HTTP standard autorisent à la fois les instructions que la ressource ne changer significativement jusqu'à une certaine date au plus tôt (pas besoin d'interroger du tout jusque-là) ou qu'il n'a pas changé depuis la dernière requête (envoyer quelques centaines d'octets d'en-têtes disant cela plutôt que plusieurs kilo-octets de données). L'amélioration de la performance peut être immense (assez grande pour déplacer la performance de quelque chose du point où il est impraticable d'utiliser au point où la performance n'est plus une préoccupation, dans certains cas).
Disponibilité des boîtes à outils: parce que cela fonctionne à un niveau relativement simple, si vous avez un serveur web, vous pouvez construire le serveur D'un système RESTful et si vous avez une sorte D'API client HTTP (XHR dans le navigateur javascript, HttpWebRequest dans. net, etc.), vous pouvez construire le client D'un système RESTful.
Résilience: en particulier, l'absence d'état partagé signifie qu'un client peut mourir et revenir en service sans que le serveur le sache, et même le serveur peut mourir et revenir en service sans que le client le sache. Évidemment les communications au cours de cette la période échouera, mais une fois que le serveur est de retour en ligne, les choses peuvent simplement continuer comme elles étaient. Cela simplifie également l'utilisation des fermes web pour la redondance et les performances-chaque serveur agit comme s'il était le seul serveur, et peu importe qu'il ne traite qu'une fraction des demandes d'un client donné.
REST N'est pas un protocole, c'est une architecture généralisée pour décrire une plate-forme de médias distribués client-serveur sans état. Une architecture REST peut être implémentée en utilisant un certain nombre de protocoles de communication différents, bien que HTTP soit de loin le plus commun.
REST N'est pas un protocole, c'est un moyen d'exposer votre application, principalement via HTTP.
Par exemple, vous souhaitez exposer une api de votre application qui fait getClientById
au lieu de créer une URL
Yourapi.com/getClientById?id=4
vous pouvez faire
yourapi.com/clients/id/4
Puisque vous utilisez une méthode GET, cela signifie que vous voulez obtenir des données
Vous profitez des méthodes HTTP: GET / DELETE / PUT
yourapi.com/clients/id/4 peut également traiter avec delete, si vous envoyez une méthode delete et ne pas obtenir, ce qui signifie que vous voulez dekete l'enregistrement
, Toutes les réponses sont bonnes.
J'ajoute ici une description détaillée de REST et comment il utilise HTTP.
REST = transfert D'État représentatif
RESTE est un ensemble de règles, qui lorsqu'il est suivi, vous permettent de créer une application distribuée qui a un ensemble de souhaitable contraintes.
Il est sans état, ce qui signifie qu'idéalement aucune connexion ne doit être maintenue entre le client et le serveur.
C'est le responsabilité du client de transmettre son contexte au serveur, puis le serveur peut stocker ce contexte pour traiter la demande ultérieure du client. Par exemple, la session gérée par le serveur est identifiée par l'identifiant de session transmis par le client.
Avantages de l'Apatridie:
- Les services Web peuvent traiter chaque appel de méthode séparément.
- Les Services Web n'ont pas besoin de maintenir l'interaction précédente du client.
- cela simplifie l'application conception.
- HTTP est lui-même un protocole sans état contrairement à TCP et donc les services web RESTful fonctionnent de manière transparente avec les protocoles HTTP.
Les Inconvénients de l'Apatridie:
- une couche supplémentaire sous forme d'en-tête doit être ajoutée à chaque requête pour préserver l'état du client.
- Pour plus de sécurité, nous pouvons avoir besoin d'ajouter une info d'en-tête à chaque requête.
Méthodes HTTP supportées par REST:
Obtenir: /string/someotherstring:
Il est idempotent (signifie que plusieurs appels doivent renvoyer les mêmes résultats à chaque fois) et devrait idéalement renvoyer les mêmes résultats chaque fois qu'un appel est effectué
Mettre:
Même chose que pour les OBTENIR. Idempotent et est utilisé pour mettre à jour les ressources.
POST: doit contenir une url et un corps
Utilisé pour créer des ressources. Plusieurs appels devraient idéalement renvoyer des résultats différents et devraient créer plusieurs produits.
Supprimer:
Utilisé pour supprimer des ressources sur le serveur.
Tête:
Le La méthode HEAD est identique à GET sauf que le serveur ne doit pas renvoyer un corps de message dans la réponse. Les méta-informations contenues dans les en-têtes HTTP en réponse à une requête HEAD doivent être identiques aux informations envoyées en réponse à une requête GET.
OPTIONS:
Cette méthode permet au client de déterminer les options et / ou les exigences associées à une ressource, ou les capacités d'un serveur, sans impliquer une action de ressource ou initier une ressource récupération.
Les Réponses HTTP
Rendez-vous ici pour toutes les réponses.
Voici quelques-uns importants:
200-OK
3XX-informations supplémentaires nécessaires à partir du client et URL redirection
400-Mauvaise demande
401-accès non autorisé
403-Interdit
La requête était valide, mais le serveur refuse l'action. Il se peut que l'utilisateur ne dispose pas des autorisations nécessaires pour une ressource ou qu'il ait besoin sorte.
404-Non Trouvé
La ressource demandée n'a pas pu être trouvée mais pourrait être disponible à l'avenir. Les demandes ultérieures du client sont autorisées.
405-Méthode Non Autorisée Une méthode de requête n'est pas prise en charge pour la ressource demandée; par exemple, une requête GET sur un formulaire qui nécessite la présentation de données via POST, ou une requête PUT sur une ressource en lecture seule.
404-requête introuvable
500-Défaillance Interne Du Serveur
502 - Erreur De Passerelle Incorrecte