Quelle est la différence entre HTTP et REST?

Après avoir lu beaucoup de choses sur les différences entre REST et SOAP, j’ai eu l’impression que REST n’est qu’un autre mot pour HTTP. Quelqu’un peut-il expliquer quelle fonctionnalité REST ajoute à HTTP?

Note : Je ne cherche pas une comparaison entre REST et SOAP.

Mise à jour : Merci pour vos réponses. Maintenant, il est devenu clair pour moi que REST n’est qu’un ensemble de règles sur la façon d’utiliser HTTP. J’ai donc posté un suivi sur les avantages de ces conventions .

Note : je saisis maintenant la signification de REST; Comme le remarque Emil Ivanov , 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 comprends certainement pas le battage médiatique.

Non, REST est la manière dont HTTP doit être utilisé .

Aujourd’hui, nous n’utilisons qu’une petite partie des méthodes du protocole HTTP, à savoir GET et POST . La façon la plus simple de le faire est d’utiliser toutes les méthodes du protocole.

Par exemple, REST dicte l’utilisation de DELETE pour effacer un document (que ce soit un fichier, un état, etc.) derrière un URI, alors qu’avec HTTP, vous utiliseriez une requête GET ou POST comme ...product/?delete_id=22 .

HTTP est un protocole utilisé pour la communication, généralement utilisé pour communiquer avec des 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 ne faites généralement que des opérations 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 pour CREATE, PUT pour UPDATE et DELETE pour DELETE). c’est différent du concept plus ancien de RPC (Appel de procédure à distance), dans lequel vous avez un ensemble d’actions que vous souhaitez effectuer suite à l’appel de l’utilisateur. Si vous pensez, par exemple, à la description d’un facebook comme sur un message, avec RPC, vous pouvez créer des services appelés AddLikeToPost et RemoveLikeFromPost, et les gérer avec tous les autres services liés aux articles FB. object pour Like avec REST, vous aurez un object Like qui sera géré séparément avec les fonctions Delete et Create. Cela signifie également qu’il décrira une entité distincte dans votre firebase database. cela peut sembler une petite différence, mais travailler de cette façon produirait généralement un code beaucoup plus simple et une application beaucoup plus simple. avec cette conception, la plupart de la logique de l’application est évidente à partir de la structure de l’object (modèle), contrairement à RPC avec lequel vous devriez généralement append explicitement beaucoup plus de logique.

La conception d’applications RESTful est généralement beaucoup plus difficile car elle nécessite de décrire des choses compliquées de 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 découvrirez que vous écrirez des méthodes beaucoup plus courtes.

Une contrainte supplémentaire de l’architecture REST présente est de ne pas utiliser le contexte de session lors de la communication avec le client (sans état), ce qui signifie que toutes les informations doivent comprendre qui est le client et ce qu’il veut transmettre avec le message Web. chaque appel à une fonction est auto-descriptif, il n’y a pas de conversation préalable avec le client pouvant ê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 n’avez pas de session pour stocker la page précédente et le type de page que vous voulez, le client doit dire “je m’appelle yuval, obtenez moi 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 trouver un bogue signalé par la fonction “get me next page” opposée à “me faire parvenir la page 2 de la question id 2190836 dans le dépassement de stack”.

Bien sûr, il y a beaucoup plus, mais à mon avis, ce sont les principaux concepts d’une cuillère à café.

REST n’ajoute aucune fonctionnalité spécifique à HTTP mais est un style architectural développé avec 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, une fois appliquées, vous permettent de créer une application dissortingbuée qui possède 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 que la contrainte “auto-description” et la contrainte hypermédia (alias Hypermedia comme moteur de l’état d’application (HATEOAS)) sont le plus important.

La contrainte d’auto-description nécessite une requête RESTful pour être complètement auto-descriptif dans l’intention de l’utilisateur. Cela permet aux intermédiaires (proxys et caches) d’agir sur le message en toute sécurité.

La contrainte HATEOAS consiste à transformer votre application en un réseau de liens où l’état actuel du client est basé sur sa place dans ce Web. C’est un concept délicat et nécessite plus de temps pour expliquer que maintenant.

Pas assez…

http://en.wikipedia.org/wiki/Representational_State_Transfer

REST a été initialement décrit dans le contexte de HTTP, mais ne se limite pas à ce protocole. Les architectures RESTful peuvent être basées sur d’autres protocoles Application Layer si elles fournissent déjà un vocabulaire riche et uniforme pour les applications basées sur le transfert d’un état représentatif significatif. Les applications RESTful optimisent l’utilisation de l’interface prédéfinie et bien définie et des autres fonctionnalités intégrées fournies par le protocole réseau choisi, et minimisent l’ajout de nouvelles fonctionnalités spécifiques aux applications.

http://www.looselycoupled.com/glossary/SOAP

(Simple Object Access Protocol) La norme pour les messages de services Web. Basé sur XML, SOAP définit un format d’enveloppe et diverses règles pour décrire son contenu. Considéré (avec WSDL et UDDI) comme l’un des trois principes de base des services Web, c’est le protocole privilégié pour l’échange de services Web, mais en aucun cas le seul; les partisans de REST disent que cela ajoute une complexité inutile.

Si je comprends bien, REST applique l’utilisation des commandes HTTP disponibles telles qu’elles étaient destinées à être utilisées.

Par exemple, je pourrais faire:

 GET http://example.com?method=delete&item=xxx 

Mais avec le repos, j’utiliserais la méthode de requête “DELETE”, en supprimant le besoin de param “query”

 DELETE http://example.com?item=xxx 

REST est une manière spécifique d’aborder la conception de grands systèmes (comme le Web).

C’est un ensemble de «règles» (ou «contraintes»).

HTTP est un protocole qui tente de respecter 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) pouvant utiliser HTTP pour transporter ces messages.

REST n’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 de représentation

REST est un ensemble de règles qui, une fois appliquées, vous permettent de créer une application dissortingbuée qui possède un ensemble spécifique de contraintes souhaitables.

REST est un protocole permettant d’échanger des messages (XML, JSON, etc.) pouvant utiliser HTTP pour transporter ces messages.

Caractéristiques:

Il est sans état, ce qui signifie que, idéalement, aucune connexion ne doit être maintenue entre le client et le serveur. Il est de la responsabilité du client de transmettre son contexte au serveur, puis le serveur peut stocker ce contexte pour traiter la demande supplémentaire du client. Par exemple, la session maintenue par le serveur est identifiée par l’identifiant de session transmis par le client.

Avantages de l’apasortingdie:

  1. Les services Web peuvent traiter chaque appel de méthode séparément.
  2. Les services Web n’ont pas besoin de maintenir l’interaction précédente du client.
  3. Cela simplifie la conception des applications.
  4. HTTP est lui-même un protocole sans état contrairement à TCP et les services Web RESTful fonctionnent donc de manière transparente avec les protocoles HTTP.

Inconvénients de l’apasortingdie:

  1. Une couche supplémentaire sous la forme d’un en-tête doit être ajoutée à chaque demande pour préserver l’état du client.
  2. Pour plus de sécurité, nous devons append une information d’en-tête à chaque requête.

Méthodes HTTP sockets en charge par REST:

GET: / ssortingng / someotherssortingng 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: doit contenir une URL et un corps Utilisé pour créer des ressources. Les appels multiples doivent idéalement renvoyer des résultats différents et créer plusieurs produits.

DELETE: Permet de supprimer des ressources sur le serveur.

TÊTE:

La méthode HEAD est identique à GET sauf que le serveur NE DOIT PAS retourner 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 DEVRAIENT ê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 fonctionnalités d’un serveur, sans impliquer une action de ressource ou lancer une récupération de ressource.

Réponses HTTP

Allez ici pour toutes les réponses .

En voici quelques-unes importantes: 200 – OK 3XX – Informations supplémentaires nécessaires à partir du client et de la 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 n’a peut-être pas les permissions 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 ultérieurement. Les demandes ultérieures du client sont autorisées.

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 requête GET sur un formulaire nécessitant la présentation de données via POST ou une requête PUT sur une ressource en lecture seule.

404 – Demande non trouvée
500 – Échec du serveur interne
502 – Erreur de passerelle incorrecte

Les API REST doivent être pilotées par hypertexte

Voici quelques façons de vérifier si vous construisez une API HTTP ou une API REST à partir du blog de Roy Fielding :

Les concepteurs d’API, veuillez noter les règles suivantes avant d’appeler votre création une API REST:

  • Une API REST ne doit dépendre d’aucun protocole de communication, bien que son mappage réussi sur 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 autoriser tout schéma d’URI à utiliser pour cette identification. [L’échec ici implique que l’identification n’est pas séparée de l’interaction.]
  • Une API REST ne doit contenir aucune modification des protocoles de communication en plus du remplissage ou de la correction des 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 cassées (telles que les navigateurs assez stupides pour croire que HTML définit l’ensemble de méthodes HTTP) doivent être définies séparément, ou du moins dans les annexes, en espérant que la solution de contournement sera éventuellement obsolète. [Echec ici implique que les interfaces de ressources sont spécifiques à l’object, pas génériques.]
  • Une API REST doit consacrer presque tout son effort descriptif à définir le ou les types de média utilisés pour représenter les ressources et piloter l’état de l’application, ou à définir des noms de relations étendues et / ou des balises hypertexte pour les types de supports standard existants. Tout effort consacré à la description des méthodes à utiliser sur quels URI d’intérêt doit être entièrement défini dans le cadre des règles de traitement pour un type de média (et, dans la plupart des cas, déjà défini par les types de média existants). [L’échec ici implique que les informations hors bande entraînent une interaction plutôt qu’un hypertexte.]
  • Une API REST ne doit pas définir de noms de ressources ou de hiérarchies fixes (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 des URI appropriés, comme 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 liens. [L’échec ici implique que les clients supposent une structure de ressources due à des informations hors bande, telles qu’une norme spécifique au domaine, qui est l’équivalent orienté données du couplage fonctionnel de RPC].
  • Une API REST ne devrait jamais avoir “tapé” des ressources significatives pour le client. Les auteurs de spécifications peuvent utiliser des types de ressources pour décrire l’implémentation 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 média de la représentation actuelle et les noms de relation standardisés. [idem]
  • Une API REST doit être saisie sans connaissance préalable au-delà de l’URI initial (signet) et de l’ensemble des types de média standardisés adaptés à l’audience visée (c.-à-d. Censé être compris par tout client pouvant utiliser l’API). À partir de ce moment, toutes les transitions d’état de l’application doivent être pilotées par la sélection par le client des choix fournis par le serveur qui sont présents dans les représentations reçues ou impliquées 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, qui peuvent tous deux être améliorés à la volée (par exemple, code à la demande). [L’échec ici implique que les informations hors bande entraînent une interaction plutôt qu’un hypertexte.]

HTTP is a contract, a communication protocol and REST is a concept, an architectural style pouvant utiliser HTTP, FTP ou d’autres protocoles de communication, mais 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 , le plus souvent utilisé dans l’API REST, simplement parce que REST was inspired by WWW (world wide web) which largely used HTTP avant la définition de REST. Style API avec HTTP.

 There are three major constraints in REST (but there are more): 

1. interaction entre le serveur et le client doit être décrite via un hypertexte uniquement.

2. serveur et le client doivent être faiblement couplés et ne pas faire d’hypothèses. Le client ne doit connaître que le point d’entrée de la ressource. Les données d’interaction doivent être fournies par le serveur dans la réponse.

3. serveur ne doit stocker aucune information sur le contexte de la requête. Les demandes doivent être indépendantes et idempotentes (signifie que si la même demande est répétée à l’infini, le même résultat est récupéré)

Et HTTP est juste un protocole de communication (un outil) qui peut aider à atteindre cet objective.

Pour plus d’infos consultez ces liens:

https://martinfowler.com/articles/richardsonMaturityModel.html http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven