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 quelles fonctionnalités REST ajoute à HTTP?

Remarque : je ne cherche pas à comparer 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 .

Remarque : je saisis maintenant le sens de REST; comme le remarque Emil Ivanov , REST signifie utiliser HTTP comme il est censé être. Cependant, je ne sais pas si cela mérite un terme qui lui est propre, et je ne comprends certainement pas le battage médiatique autour.

Non, REST est la façon dont HTTP doit être utilisé .

Aujourd'hui, nous n'utilisons qu'une infime partie des méthodes du protocole HTTP - à savoir GETet POST. La façon REST de le faire est d'utiliser toutes les méthodes du protocole.

Par exemple, REST dicte l'utilisation de DELETEpour effacer un document (que ce soit un fichier, un état, etc.) derrière un URI, alors qu'avec HTTP, vous abuseriez d'un GETou d' une POSTrequête 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 n'effectuez généralement qu'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). c'est différent de l'ancien concept de RPC (Remote Procedure Call), dans lequel vous avez un ensemble d'actions que vous souhaitez effectuer à la suite de l'appel de l'utilisateur. si vous pensez par exemple à décrire un facebook comme sur un post, avec RPC vous pouvez créer des services appelés AddLikeToPost et RemoveLikeFromPost, et le gérer avec tous vos autres services liés aux publications FB, vous n'aurez donc pas besoin de créer de spécial objet pour Like. avec REST, vous aurez un objet Like qui sera géré séparément avec les fonctions Supprimer et Créer. Cela signifie également qu'il décrira une entité distincte dans votre base de données. cela pourrait ressembler à une petite différence, mais travailler comme cela donnerait 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'objet (modèle), contrairement au RPC avec lequel vous devriez généralement ajouter explicitement beaucoup plus de logique.

la conception d'une application RESTful est généralement beaucoup plus difficile car elle vous oblige à 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 constaterez que vous écrirez des méthodes beaucoup plus courtes.

Une autre architecture REST de contrainte 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 être transmis avec le 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 n'avez pas de session pour stocker quelle est la page précédente et quel type de page vous voulez, le client devrait dire "mon nom est yuval, obtenez 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 trouver un bogue signalé par la fonction "obtenez-moi la page suivante" en opposition à "

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

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 qui a un ensemble spécifique de contraintes souhaitables.

Si vous recherchez les contraintes REST les plus importantes 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 en tant que Engine of Application State (HATEOAS)) sont le plus important.

La contrainte d'auto-description nécessite qu'une requête RESTful soit complètement auto-descriptive dans l'intention des utilisateurs. 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 réseau de liens où l'état actuel du client est basé sur sa place dans ce site. C'est un concept délicat et nécessite plus de temps pour expliquer que je n'en ai actuellement.

Si je comprends bien, 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 du repos, j'utiliserais la méthode de requête "SUPPRIMER", supprimant le besoin du paramètre de requête "méthode"

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

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. Les architectures RESTful peuvent être basées sur d'autres protocoles de couche application si elles fournissent déjà un vocabulaire riche et uniforme pour les applications basé sur le transfert d'un état de représentation significatif. Les applications RESTful maximisent l'utilisation de l'interface préexistante et bien définie et d'autres capacités intégrées fournies par le protocole réseau choisi, et minimisent l'ajout de nouvelles fonctionnalités spécifiques à l'application par-dessus.

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'une des trois normes de base des services Web, c'est le protocole préféré pour l'échange de services Web, mais en aucun cas le seul; les partisans de REST disent qu'il ajoute une complexité inutile.

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 essaie d'obéir à ces règles.

REST = transfert d'état représentatif

REST est un ensemble de règles qui, lorsqu'elles sont suivies, vous permettent de créer une application distribuée qui a un ensemble spécifique de contraintes souhaitables.

REST est un protocole pour échanger tous les messages (XML, JSON, etc.) qui peuvent utiliser HTTP pour transporter ces messages.

Fonctionnalités:

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 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:

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 à son tour la conception des applications.
4. 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.

Inconvénients de l'apatridie:

1. Une couche supplémentaire sous forme d'en-tête doit être ajoutée à chaque demande pour préserver l'état du client.
2. Pour des raisons de sécurité, nous devons ajouter des informations d'en-tête à chaque demande.

Méthodes HTTP prises en charge par REST:

GET: / string / someotherstring Il est idempotent et devrait idéalement retourner les mêmes résultats chaque fois qu'un appel est effectué

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. Idéalement, plusieurs appels devraient 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 retourner un 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 capacité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-uns importants: 200 - OK 3XX - Informations supplémentaires requises du client et redirection d'URL 400 - Mauvaise demande
401 - Accès non autorisé
403 - Interdit
La demande était valide, mais le serveur refuse toute action. L'utilisateur peut ne pas disposer des 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 à l'avenir. 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 demande GET sur un formulaire qui nécessite la présentation de données via POST, ou une demande PUT sur une ressource en lecture seule.

404 - Demande introuvable
500 - Échec du serveur interne
502 - Erreur de passerelle incorrecte

HTTP est un protocole de communication qui transporte des messages sur un réseau. SOAP est un protocole pour échanger des messages XML qui peuvent utiliser HTTP pour transporter ces messages. Rest est un protocole pour échanger tous les messages (XML ou JSON) qui peuvent utiliser HTTP pour transporter ces messages.

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 REST was inspired by WWW (world wide web) which largely used HTTPqu'avant la définition de REST, 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 uniquement par hypertexte.

2.Le serveur et le client doivent être couplés de manière lâche et ne faire aucune hypothèse l'un sur l'autre. 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 doit pas stocker d'informations sur le contexte de la demande. Les demandes doivent être indépendantes et idempotentes (signifie que si la même demande est répétée à l'infini, exactement le même résultat est récupéré)

Et HTTP n'est qu'un protocole de communication (un outil) qui peut aider à y parvenir.

Pour plus d'informations, consultez ces liens:

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

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

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 l'un de l'autre, mais le protocole HTTP 1.1 a été conçu pour être le protocole idéal pour suivre les principes et les contraintes de REST. Une façon d'examiner la relation entre HTTP et REST est que REST est la conception et HTTP 1.1 est une implémentation de cette conception.

Les API REST doivent être basées sur l'hypertexte

Sur le blog de Roy Fielding, voici un ensemble de façons de vérifier si vous créez 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 mise en 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 qui utilise un URI pour l'identification doit permettre 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 dehors du remplissage ou de la correction des détails des bits non 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 suffisamment stupides pour croire que HTML définit l'ensemble de méthodes HTTP) devraient être définies séparément, ou du moins dans les annexes, en s'attendant à ce que la solution de contournement soit finalement obsolète. [L'échec ici implique que les interfaces de ressources sont spécifiques à l'objet, et non 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 relation étendus et / ou un balisage hypertexte pour les types de média standard existants. Tout effort consacré à décrire les méthodes à utiliser sur les URI d'intérêt devrait être entièrement défini dans le cadre des règles de traitement pour un type de support (et, dans la plupart des cas, déjà défini par les types de support existants). [L'échec ici implique que les informations hors bande conduisent à l'interaction plutôt qu'à l'hypertexte.]
• Une API REST ne doit pas définir de noms ou de hiérarchies de ressources 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 à expliquer aux clients comment construire des URI appropriés, comme cela se fait dans les formulaires HTML et les modèles d'URI, en définissant ces instructions dans les types de médias et les relations de liaison. [L'échec ici implique que les clients supposent une structure de ressources en raison d'informations hors bande, comme une norme spécifique au domaine, qui est l'équivalent orienté données du couplage fonctionnel du RPC].
• Une API REST ne doit jamais avoir de ressources «typées» importantes 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 entrée sans aucune connaissance préalable au-delà de l'URI initial (signet) et un ensemble de types de médias standardisés qui sont appropriés pour le public visé (c'est-à-dire, censés être compris par tout client qui pourrait utiliser l'API). À partir de ce moment, toutes les transitions d'état d'application doivent être déterminé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és par la manipulation par l'utilisateur de ces représentations. Les transitions peuvent être déterminées (ou limitées par) la connaissance du client des types de médias et des mécanismes de communication des ressources, qui peuvent tous deux être améliorés à la volée (par exemple, le code à la demande). [L'échec ici implique que les informations hors bande conduisent à l'interaction plutôt qu'à l'hypertexte.]