Que signifie exactement REST ? Qu'est-ce que c'est, et pourquoi est-ce que ça prend de l'ampleur maintenant ?

Question

I comprendre (je pense) l'idée de base derrière RESTful-ness. Utiliser les méthodes HTTP de manière sémantique - GET obtient, PUT met, DELETE supprime, etc... Pas vrai ? Je pensais avoir compris l'idée derrière REST, mais je pense que je confonds cela avec les détails d'une implémentation HTTP. Quelle est l'idée maîtresse derrière REST, pourquoi est-ce que cela devient une chose importante ? Les gens l'utilisent-ils depuis longtemps, dans un coin de l'Internet que je n'ai jamais vu ?

---

Le discours de Google mentionne que les protocoles de publication Atom ont une grande synergie avec les implémentations RESTful. Qu'en pensez-vous ?

Answer 1

Voici à quoi REST pourrait ressembler :

POST /user
fname=John&lname=Doe&age=25

Le serveur répond :

201 Created
Location: /user/123

Dans le futur, vous pourrez alors récupérer les informations sur l'utilisateur :

GET /user/123

Le serveur répond (en supposant une réponse XML) :

200 OK
<user><fname>John</fname><lname>Doe</lname><age>25</age></user>

Pour mettre à jour :

PUT /user/123
fname=Johnny

Answer 2

Voici mon point de vue...

L'intérêt de créer des services RESTful est qu'au lieu de créer des services web avec des dizaines de méthodes fonctionnelles, nous standardisons sur quatre méthodes (Créer, Récupérer, Mettre à jour, Détruire) :

• POST
• GET
• PUT
• DELETE

REST devient populaire parce qu'il représente également une normalisation des formats de messagerie au niveau de la couche application. Bien que HTTP utilise les quatre verbes de base de REST, le format de message HTTP commun de HTML n'est pas un contrat pour la construction d'applications.

La meilleure explication que j'ai entendue est une comparaison entre TCP/IP et RSS.

Ethernet représente une normalisation sur le réseau physique. Le protocole Internet (IP) représente une normalisation plus élevée dans la pile, et a plusieurs saveurs différentes (TCP, UDP, etc.). L'introduction du "Transmission Control Protocol" (livraison garantie des paquets) a défini des contrats de communication qui nous ont ouvert à toute une série de nouveaux services (FTP, Gopher, Telnet, HTTP) pour la couche application.

Dans l'analogie, nous avons adopté le XML comme "protocole", nous commençons maintenant à normaliser les formats de message. RSS devient rapidement la base de nombreux services RESTful. L'API GData de Google est une variante de RSS/ATOM.

Le "gadget de bureau" est une excellente illustration de ce phénomène : un simple client peut consommer du contenu web de base ou des mélanges complexes en utilisant une API et une norme de messagerie communes.

Answer 3

Le protocole HTTP est actuellement sous-utilisé et mal utilisé.

Nous n'utilisons généralement que deux méthodes HTTP : GET et POST, mais il en existe d'autres : DELETE, PUT, etc ( http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html )

Ainsi, si nous avons des ressources, définies par des URL RESTful (chaque objet de domaine dans votre application a une URL unique sous forme de http://yoursite.com/path/to/the/resource ) et une implémentation HTTP décente, nous pouvons manipuler les objets de votre domaine en écrivant des phrases :

GET http://yoursite.com/path/to/the/resource

DELETE http://yoursite.com/path/to/the/resource

POST http://yoursite.com/path/to/the/resource

etc.

l'architecture est belle et tout.

mais ce n'est qu'une vue théorique, les scénarios du monde réel sont décrits dans tous les liens postés dans les réponses avant la mienne.

Answer 4

Il y a une très bonne introduction à REST dans le livre Services Web RESTful par Leonard Richardson et Sam Ruby ( http://oreilly.com/catalog/9780596529260/ )

Pour la définition originale du style architectural REST, voir la dissertation de Roy Fielding ( http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm )

Salutations, tamberg

Answer 5

REST est une architecture où les ressources sont définies et adressées.

Pour mieux comprendre REST, il faut se pencher sur l'outil Architecture orientée ressources (ROA) qui donne un ensemble de lignes directrices pour la mise en œuvre de l'architecture REST.

REST ne doit pas nécessairement passer par HTTP, mais c'est le plus courant. REST a d'abord été créé par l'un des créateurs de HTTP.