Discussion :

[af.zakaria]

Bonjour,

Je développe sous Android et j'utilise les web services en se basant juste sur des requetes HTTP et parsant les données sous format JSON.

J'entends toujours du Web Service REST mais j'ai aucune idée sur les points forts de REST et la différence avec HTTP.

J'aimerai bien savoir les avantages du REST et sa différence avec HTTP.

Je travaille avec HTTP puisque il est facile. Il se peut que je travaillerai avec REST si je le trouve plus puissant.

Merci bien pour vos renseignements.

[nicroman]

Une énorme différence, il ne correspondent pas du tout à la même couche ISO des réseaux:

Couche P/L (physique et liaison:3G, WiFi, ...)
Couche N (réseau: IP)
Couche T (transport: TCP)
Couche S (session: HTTP)
Couches P & A (présentation et application: JSON, REST, XML-RPC, SOAP, ...).


REST est basé sur HTTP (en fait, REST est même du "pur" HTTP). Hélas le terme est fortement galvaudé par des webservices qui s'annoncent REST mais n'en sont pas vraiment (voir ci-dessous pourquoi), du coup, on parle maintenant de HATEOAS ( Hypermedia as the Engine of Application State).

REST (Representational State Transfer) est donc basé sur les principes initiaux d'HTTP, à savoir: verbe (GET,POST,PUT,DELETE, mais aussi n'importe quel autre verbe, HTTP n'est pas limité à ceux là) une URI (l'objet sur lequel le verbe doit être appliqué).

Ainsi, un webservice classique verra son verbe indiqué par l'URL (fonction), et l'objet indiqué dans les paramètres. Cette approche est la plus facilement implémentable coté serveur (mais aussi la plus difficile à rendre transparente coté clients).
Un service REST fera l'inverse: l'URL indique l'objet, le verbe HTTP la fonction....

Il y a ainsi quelques restrictions à REST:
* Le service doit être complètement stateless (le serveur ne peut donc retenir aucune information concernant le client).
* Cacheable, toutes les requêtes de présentation telles que GET doivent pouvoir être cachées par les proxy intermédiaire.
* Les URIs doivent être fixes et définies.

Ainsi par exemple

Web service normal:
GET /monserveur/servlet/getUsers.php
en REST:
GET /monserveur/restlet/users

Récupérer les informations d'un utilisateur d'id 8882:
Web service normal:
GET /monserveur/servlet/getUserInfo.php?id=8882
en REST:
GET /monserveur/restlet/users/8882

Ajouter un utilisateur:
Web service normal:
POST /monserveur/servlet/addUser.php
en REST:
POST /monserveur/restlet/users

Supprimer l'utilisateur 8887
Web service normal:
POST /monserveur/servlet/deleteUser.php?id=8887
en REST:
DELETE /monserveur/restlet/users/8887

Modifier l'utilisateur 8882
Web service normal:
POST /monserveur/servlet/updateUser.php?id=8882
en REST:
PUT /monserveur/restlet/users/8882


Attention à la différence entre PUT et POST....
Si on envoie les même informations plusieurs fois au serveur, si le résultat est inchangé => c'est un PUT (par exemple PUT des données modifiées d'un utilisateur, si on renvoie la même requête, rien ne sera changé => PUT)
Si le résultat change => c'est un POST (par exemple rajouter un utilisateur dont on ne connait pas l'identifiant, si on renvoie la même requête, il y a des chances pour que deux utilisateurs soient créés => POST)

GET = nullipotent (aucun changement de données, aucun side-effect)
PUT/DELETE = idempotent (les même requêtes ré-exécutées ne changent pas les données).