Quelle est la différence entre HTTP et REST?
Après avoir beaucoup lu sur les différences entre REST et SOAP, j'ai eu l'impression que REST n'était qu'un autre mot pour HTTP. Quelqu'un peut-il expliquer quelle fonctionnalité REST ajoute à HTTP?
Remarque: Je ne cherche pas à comparer REST par rapport à SOAP.
Mettre à jour: Merci pour vos réponses. Maintenant, il m'est apparu que REST n'était qu'un ensemble de règles sur l'utilisation de HTTP. J'ai donc posté un suivi sur quels sont les avantages de ces conventions .
Remarque: Je comprends maintenant le sens de REST; Comme Emil Ivanov remarque, REST signifie utiliser HTTP comme il se doit. Cependant, je ne suis pas sûr que cela mérite un terme en soi, et je ne reçois certainement pas le battage médiatique autour de cela.
Non,RESTEest le moyenHTTPdevrait être utilisé.
Aujourd'hui, nous n'utilisons qu'une infime partie des méthodes du protocole HTTP, à savoir GET et POST. Le moyen le REST de le faire consiste à utiliser toutes les méthodes du protocole.
Par exemple, REST dicte l'utilisation de DELETE pour effacer un document (fichier, état, etc.) derrière un URI, alors qu'avec HTTP, vous utiliseriez de manière incorrecte une requête GET ou POST telle que ...product/?delete_id=22.
HTTP est un protocole utilisé pour la communication, généralement utilisé pour communiquer avec les ressources Internet ou toute application avec un client de navigateur Web.
REST signifie que le concept principal que vous utilisez lors de la conception de l'application est la ressource: pour chaque action que vous souhaitez effectuer, vous devez définir une ressource sur laquelle vous effectuez généralement une opération CRUD, ce qui est une tâche simple. pour cela, il est très pratique d’utiliser 4 verbes utilisés dans le protocole HTTP contre les 4 opérations CRUD (Get for Read, POST est pour CREATE, PUT est pour UPDATE et DELETE est pour DELETE) . concept de RPC (Remote Procedure Call), dans lequel vous souhaitez effectuer un ensemble d’actions à la suite de l’appel de l’utilisateur. Si vous pensez par exemple à décrire un facebook comme sur un article, RPC vous permet de créer des services appelés AddLikeToPost et RemoveLikeFromPost, et de les gérer avec tous vos autres services liés aux articles FB. Ainsi, vous n'avez pas besoin de créer des objet pour Like. avec REST vous aurez un objet Like qui sera géré séparément avec les fonctions Delete et Create. Cela signifie également que cela décrira une entité distincte dans votre base de données. cela peut sembler une petite différence, mais travailler de la sorte donnerait généralement un code beaucoup plus simple et une application beaucoup plus simple. avec cette conception, la logique de l'application est en grande partie évidente à partir de la structure (modèle) de l'objet, contrairement au RPC avec lequel vous auriez généralement à ajouter explicitement beaucoup plus de logique.
la conception d'une application RESTful est généralement beaucoup plus difficile car elle nécessite de décrire des choses compliquées d'une manière simple. Décrire toutes les fonctionnalités en utilisant uniquement les fonctions CRUD est délicat, mais après cela, votre vie serait beaucoup plus simple et vous constaterez que vous écrirez des méthodes beaucoup plus courtes.
Une architecture de contrainte REST supplémentaire consiste à ne pas utiliser le contexte de session lors de la communication avec le client (sans état), ce qui signifie que toutes les informations nécessaires pour comprendre qui est le client et ce qu'il veut sont transmises au message Web. chaque appel à une fonction est auto-descriptif, il n'y a pas de conversation précédente avec le client qui puisse être référencée dans le message. Par conséquent, un client ne peut pas vous dire "donnez-moi la page suivante" car vous ne disposez pas d'une session pour stocker la page précédente et le type de page que vous souhaitez, le client doit dire "mon nom est yuval, get moi la page 2 d'un article spécifique dans un forum spécifique ". cela signifie qu'un peu plus de données devraient être transférées dans la communication, mais pensez à la différence entre la recherche d'un bogue signalé par la fonction "obtenez-moi page suivante" et opposez-vous à "obtenez-moi la page 2 de la question ID 2190836 dans le dépassement de pile".
Bien sûr, il y a beaucoup plus que cela, mais à mon avis ce sont les concepts principaux dans une cuillère à café.
RESTE n'ajoute aucune fonctionnalité spécifique à HTTP, mais constitue un style architectural développé parallèlement à HTTP et utilise le plus souvent HTTP pour son protocole de couche application.
HTTP est un protocole d'application. REST est un ensemble de règles qui, lorsqu'elles sont suivies, vous permettent de créer une application distribuée comportant un ensemble spécifique de contraintes souhaitables.
Si vous recherchez les contraintes les plus importantes de REST qui distinguent une application RESTful de n'importe quelle application HTTP, je dirais la contrainte "auto-description" et la contrainte hypermédia (alias Hypermedia en tant que moteur de l'état d'application ( HATEOAS)) sont les plus importants.
La contrainte d'auto-description nécessite qu'une demande RESTful soit complètement auto-descriptive dans l'intention de l'utilisateur. Cela permet aux intermédiaires (mandataires et caches) d’agir en toute sécurité sur le message.
La contrainte HATEOAS consiste à transformer votre application en un Web de liens où l'état actuel du client est basé sur sa place dans ce Web. C'est un concept délicat qui nécessite plus de temps pour expliquer que ce que j'ai actuellement.
Pas assez...
http://en.wikipedia.org/wiki/Representational_State_Transfer
REST a été initialement décrit dans le contexte de HTTP, mais n'est pas limité à ce protocole. Architectures reposantes peut être basé sur une autre application Protocoles de couche s'ils existent déjà fournir un vocabulaire riche et uniforme pour les applications basées sur le transfert d'un état de représentation significatif . Les applications RESTful maximisent l'utilisation du préexistant, bien défini interface et autres fonctions intégrées capacités fournies par le choisi protocole de réseau et minimiser le ajout de nouvelles applications spécifiques caractéristiques sur le dessus.
http://www.looselycoupled.com/glossary/SOAP
(Simple Object Access Protocol) Le norme pour les messages de services Web . Basé sur XML, SOAP définit une enveloppe format et diverses règles pour décrivant son contenu. Vu (avec WSDL et UDDI) comme l’un des trois normes de base des services Web, c'est le protocole préféré pour échange de services Web, mais par no signifie le seul; les partisans de REST dire que cela ajoute inutile complexité.
Si j'ai bien compris, REST impose l'utilisation des commandes HTTP disponibles telles qu'elles étaient censées être utilisées.
Par exemple, je pourrais faire:
GET
http://example.com?method=delete&item=xxx
Mais avec reste, j'utiliserais la méthode de requête "DELETE", supprimant ainsi le besoin du paramètre de requête "méthode"
DELETE
http://example.com?item=xxx
REST est une manière spécifique d'aborder la conception de gros systèmes (comme le Web).
C'est un ensemble de "règles" (ou "contraintes").
HTTP est un protocole qui tente d'obéir à ces règles.
HTTP est un protocole de communication qui transporte des messages sur un réseau . SOAP est un protocole permettant d'échanger des messages XML pouvant utiliser HTTP pour transporter ces messages . Rest est un protocole permettant d'échanger des messages (XML ou JSON). qui peut utiliser HTTP pour transporter ces messages.
RESTEn'est pas nécessairement lié àHTTP. Les services Web RESTful ne sont que des services Web qui suivent une architecture RESTful.
What is Rest -
1- Client-server
2- Stateless
3- Cacheable
4- Layered system
5- Code on demand
6- Uniform interface
REST = Transfert d'état représentationnel
RESTE est un ensemble de règles qui, lorsqu'elles sont suivies, vous permettent de créer une application distribuée comportant un ensemble spécifique de contraintes souhaitables.
RESTE est un protocole permettant d'échanger tout message (XML, JSON, etc.) pouvant utiliser HTTP pour transporter ces messages.
Caractéristiques:
Il est sans état, ce qui signifie qu’idéalement, aucune connexion ne doit être maintenue entre le client et le serveur. Il incombe au client de transmettre son contexte au serveur, qui peut ensuite 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'identificateur 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 ne doivent pas nécessairement conserver la précédente interaction du client.
- Cela simplifie à son tour la conception des applications.
- HTTP est lui-même un protocole sans état contrairement à TCP et, par conséquent, les services Web RESTful fonctionnent de manière transparente avec les protocoles HTTP.
Inconvénients de l'apatridie:
- Une couche supplémentaire sous la forme d'en-tête doit être ajoutée à chaque demande pour préserver l'état du client.
- Pour des raisons de sécurité, nous devons ajouter une information d’en-tête à chaque demande.
Méthodes HTTP prises en charge par REST:
GET:/string/someotherstring Il est idempotent et devrait idéalement renvoyer les mêmes résultats à chaque appel.
PUT: Identique à GET. Idempotent et est utilisé pour mettre à jour les ressources.
POST: devrait contenir une URL et un corps Utilisés pour la création de ressources. Plusieurs appels devraient idéalement renvoyer des résultats différents et créer plusieurs produits.
DELETE: Utilisé pour supprimer des ressources sur le serveur.
TÊTE:
La méthode HEAD est identique à GET sauf que le serveur NE DOIT PAS renvoyer de corps de message dans la réponse. Les méta-informations contenues dans les en-têtes HTTP en réponse à une demande HEAD DEVRAIENT être identiques aux informations envoyées en réponse à une demande GET.
OPTIONS:
Cette méthode permet au client de déterminer les options et/ou les exigences associées à une ressource, ou les fonctionnalités d'un serveur, sans impliquer d'action de ressource ni de lancement d'une récupération de ressource.
Réponses HTTP
Allez ici pour toutes les réponses .
Voici quelques exemples importants: 200 - OK 3XX - Informations supplémentaires requises du client et redirection d’URL 400 - Requête incorrecte
401 - Accès non autorisé
403 - Interdit
La demande était valide, mais le serveur refuse l'action. L'utilisateur peut ne pas avoir les autorisations nécessaires pour une ressource ou peut avoir besoin d'un compte quelconque.
404 - introuvable
La ressource demandée est introuvable mais peut être disponible dans le futur. Les demandes ultérieures du client sont acceptables.
405 - Méthode non autorisée Une méthode de demande n'est pas prise en charge pour la ressource demandée; Par exemple, une demande GET sur un formulaire nécessitant la présentation de données via POST ou une demande PUT sur une ressource en lecture seule.
404 - Requête non trouvée
500 - Panne de serveur interne
502 - Erreur de passerelle incorrecte
De Vous ne connaissez pas la différence entre HTTP et REST
L'architecture REST et le protocole HTTP 1.1 sont donc indépendants les uns des autres autre, mais le protocole HTTP 1.1 a été conçu pour être le protocole idéal pour suivez les principes et les contraintes de REST. Une façon de regarder le La relation entre HTTP et REST est que REST est la conception, et HTTP 1.1 est une implémentation de cette conception.
HTTP is a contract, a communication protocol and REST is a concept, an architectural style qui peut utiliser HTTP, FTP ou d'autres protocoles de communication mais est largement utilisé avec HTTP.
REST implies a series of constraints about how Server and Client should interact. HTTP is a communication protocol with a given mechanism for server-client data transfer, il est le plus souvent utilisé dans l'API REST simplement parce que REST was inspired by WWW (world wide web) which largely used HTTP avant REST a été défini. Il est donc plus facile d'implémenter le style d'API REST avec HTTP.
There are three major constraints in REST (but there are more):
1. L'interaction entre le serveur et le client doit être décrite via l'hypertexte uniquement.
2. Le serveur et le client doivent être couplés de manière lâche et ne faire aucune hypothèse les uns sur les autres. Le client ne doit connaître que le point d’entrée des ressources. Les données d'interaction doivent être fournies par le serveur dans la réponse.
3. Le serveur ne devrait stocker aucune information sur le contexte de la demande. Les requêtes doivent être indépendantes et idempotentes (signifie que si la même requête est répétée indéfiniment, le même résultat est récupéré)
Et HTTP n'est qu'un protocole de communication (un outil) qui peut aider à atteindre cet objectif.
Pour plus d'informations, consultez ces liens:
https://martinfowler.com/articles/richardsonMaturityModel.htmlhttp://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven
REST Les API doivent être pilotées par hypertexte
Sur le blog de Roy Fielding voici un ensemble de façons de vérifier si vous construisez une API HTTP ou une API REST:
Concepteurs d’API, veuillez noter les règles suivantes avant d’appeler votre création une API REST:
- Une API REST ne doit pas dépendre d'un seul protocole de communication, bien que sa correspondance réussie avec un protocole donné puisse dépendre de la disponibilité des métadonnées, du choix des méthodes, etc. En général, tout élément de protocole utilisant un URI pour l'identification doit permettre à tout schéma d'URI d'être utilisé dans le but de cette identification. [Un échec implique ici que l'identification ne soit pas séparée de l'interaction.]
- Une API REST ne doit contenir aucun changement dans les protocoles de communication, à part remplir ou corriger les détails des bits sous-spécifiés des protocoles standard, tels que la méthode PATCH de HTTP ou le champ d’en-tête Link. Les solutions de contournement pour les implémentations défectueuses (telles que les navigateurs assez stupides pour croire que HTML définit le jeu de méthodes HTTP) doivent être définies séparément, ou du moins dans des annexes, en espérant que la solution de contournement sera éventuellement obsolète. [Un échec implique que les interfaces de ressources soient spécifiques à un objet et non génériques.]
- Une API REST doit consacrer la quasi-totalité de ses efforts descriptifs à la définition du ou des types de support utilisés pour représenter les ressources et piloter l'état de l'application, ou à la définition de noms de relations étendues et/ou de balises hypertextes pour les normes existantes. types de médias. Tous les efforts consacrés à la description des méthodes à utiliser pour les URI d’intérêt doivent être entièrement définis dans le cadre des règles de traitement pour un type de support (et, dans la plupart des cas, déjà définis par les types de support existants). [Un échec implique que les informations hors bande génèrent une interaction plutôt qu'un hypertexte.]
- Une API REST ne doit pas définir de noms de ressources fixes ni de hiérarchies (un couplage évident entre client et serveur). Les serveurs doivent avoir la liberté de contrôler leur propre espace de noms. Au lieu de cela, autorisez les serveurs à indiquer aux clients comment construire les URI appropriés, comme cela est fait dans les formulaires HTML et les modèles d'URI, en définissant ces instructions dans les types de média et les relations de liaison. [Un échec implique que les clients assument une structure de ressources en raison d’informations hors bande, telles qu’une norme propre à un domaine, qui est l’équivalent orienté données du couplage fonctionnel de RPC].
- Une API REST ne doit jamais avoir de ressources «typées» significatives pour le client. Les auteurs de spécifications peuvent utiliser des types de ressources pour décrire la mise en œuvre du serveur derrière l'interface, mais ces types doivent être non pertinents et invisibles pour le client. Les seuls types significatifs pour un client sont le type de support de la représentation actuelle et les noms de relation standardisés. [idem]
- Une API REST doit être entrée sans aucune connaissance préalable au-delà de l'URI initial (signet) et d'un ensemble de types de supports normalisés appropriés pour le public visé (c'est-à-dire qu'il doit être compris par tout client susceptible d'utiliser l'API). . À partir de ce moment, toutes les transitions d’état d’application doivent être dictées par la sélection par le client des choix fournis par le serveur, présents dans les représentations reçues ou impliqués par la manipulation de ces représentations par l’utilisateur. Les transitions peuvent être déterminées (ou limitées par) la connaissance par le client des types de média et des mécanismes de communication des ressources, ces deux éléments pouvant être améliorés à la volée (par exemple, le code à la demande). [Un échec implique que les informations hors bande génèrent une interaction plutôt qu'un hypertexte.]