Qu’est-ce que REST ? (1/3)

REST (Representational State Transfer) est l’un de ces acronymes qui représente une non technologie comme peuvent l’être Ajax, DHTML, Web 2.0 et autres.

REST est un style d’architecture qui repose sur le protocole HTTP : On accède à une ressource (par son URI unique) pour procéder à diverses opérations (GET lecture / POST écriture / PUT modification / DELETE suppression), opérations supportées nativement par HTTP.

Dans cette série d’articles nous allons effectuer quelques rappels sur REST, écrire un client REST, puis écrire un serveur REST sans utiliser ni framework ni bibliothèque tierce, simplement en profitant des fonctionnalités natives du langage PHP.

Principes d’une architecture REST

Supposons que nous voulons réaliser un serveur REST pour gérer les livres d’une bibliothèque. Nous devons pouvoir ajouter (POST), modifier (PUT), Lire (GET) et Supprimer (DELETE) ces livres (la ressource à manipuler).

L’adresse de notre bibliothèque représente le « point terminal » (endpoint) : http://bibliotheque/. (si notre bibliothèque n’était pas uniquement un serveur REST, notre point terminal pourrait être http://bibliotheque/rest/). Le point terminal n’est ni plus ni moins l’adresse de notre webservice.

Notre bibliothèque contient des ressources, en particulier des livres, qui pourront être manipulés à une URI formée par convention de la sorte : http://point_terminal/nom_de_ressource/, soit dans notre exemple http://bibliotheque/livre/.

Nous pourrons effectuer plusieurs manipulation sur ces livres :

  • Les lire : Requête de type GET sur http://bibliotheque/livre/ID_DU_LIVRE_A_LIRE
  • En écrire : Requête de type POST sur http://bibliotheque/livre/. Le corps du message POST représente le contenu du nouveau livre à créer. A la charge de la bibliothèque d’affecter un identifiant à notre nouveau livre.
  • Les modifier : Requête de type PUT sur http://bibliotheque/livre/ID_DU_LIVRE. Le corps du message PUT représente le contenu modifié du livre d’identifiant ID_DU_LIVRE.
  • Les supprimer : Requête de type DELETE sur http://bibliotheque/livre/ID_DU_LIVRE.

Les formats d’échange

REST n’impose ni ne revendique un format d’échange entre client et serveur.

Vous êtes libre de représenter vos données en XML, en JSON, en PHP sérialisé, en MessagePack ou dans tout autre dialecte de votre propre cru (sans oublier que le but est souvent d’exposer des services vers l’extérieur).

Il n’est pas rare que les services REST permettent au client d’indiquer le format dans lequel ils souhaitent dialoguer, sous la forme par exemple d’un paramètre supplémentaire dans l’URL, ou plus simplement grâce aux en tête HTTP en spécifiant le content-type.

Tester un service REST

Pour tester un service REST, nous pouvons utiliser notre navigateur WEB (au moins pour les requêtes de lecture).

Par exemple, pour tester les API REST de Flickr, les liens suivants sont parfaitement opérationnels :

Au delà de la théorie

Si REST met en avant le protocole HTTP en proposant la manipulation de ressources interrogées via le bon verbe (GET/POST/PUT/DELETE), on continue de parler d’architectures REST dès lors qu’il s’agit de fournir des services sous la forme de méthodes accessibles via une URI.

Ainsi, il n’est pas rare de voir des architectures REST présentant des URI de type :

http://monserveur/rest/?method=nom_de_methode&parametre=parametre_de_methode

Au lieu du « standard théorique »

http://monserveur/rest/ressource/id_ressource

De même, il n’est pas rare de voir des API simplifiées qui n’utiliseront que GET pour les opérations de lecture et POST pour toutes les autres opérations (création, modification et supression).

//Exemples accessible en POST et non nécessairement en PUT / DELETE

http://monserveur/rest/?methode=supprime_commentaire&id=1


http://monserveur/rest/?methode=modifier_commentaire&id=2

Quelle est la différence entre REST et RESTful ?

Régulièrement vous pourrez lire REST ou RESTful lorsque la technologie est abordée. En bref, il n’y a aucune différence, RESTful est simplement l’adjectif qui qualifie une architecture de type REST.

Quelles sont les différences entre SOAP et REST ?

REST et SOAP sont tous les deux des architectures utilisées pour fournir des services web. Contrairement à ce que l’acronyme SOAP laisse entendre (Simple Object Access Protocol), REST est souvent utilisé lorsque la simplicité de mise en oeuvre est recherchée.

REST est lisible (pas d’enveloppe XML superflue) et facile à tester (un navigateur suffit) tout en étant facile de mise en oeuvre (un script PHP classique peut souvent être considéré comme RESTful).

SOAP reste toutefois intégré dans de nombreux outils de développements (possibilité d’export de classes en webservices, possibilité de génération automatique de clients à partir des WSDL) et permet des contrôles forts sur les types de données attendus.

Pièges à éviter

Ne passez pas des paramètres critiques dans l’URI de vos services REST !

Les paramètres d’url ne sont jamais sûrs !

Que le service soit distribué ou non en https, ne proposez jamais un script de la forme

http[s]://monserveur/rest/?method=methode&mot_de_passe=valeur_secrete

Liens

Suite de l’article

Ressources externes

  1. >Ainsi, il n’est pas rare de voir des architectures REST présentant des méthodes de type :
    >http://monserveur/rest/?methode=supprime_commentaire&id=1

    non, ce n’est pas du REST. Puisqu’ici on n’utilise pas le verbe HTTP pour indiquer l’action, mais un paramètre d’URI. Là il y a clairement abus de langage.

    • En fait, j’ai un peu simplifié, je vais corriger car cela prête à confusion.

      Deux choses que je voulais dire :
      - Il n’est pas rare de voir des API dites REST qui simplifient les verbes avec GET et POST (en faisant l’impasse sur PUT et DELETE).

      - Il n’est pas rare de voir des URI qui ne représentent pas le standard (/nomressource/id accédées via un verbe donné) mais simplement endpoint/?methode=qqchose&…

      En effet, un GET sur http://monserveur/rest/?methode=supprime_commentaire&id=1 est une mauvaise pratique (une écriture ne devrait pas se faire en « GET »)

      EDIT: Article modifié pour clarifier l’exemple

  2. Je me corrige : l’exemple indiqué peut être considéré comme du REST (si on s’en fie à la définition wikipedia), par contre, ce n’est pas du RESTFull, qui repose sur HTTP et impose l’utilisation des verbes HTTP.

  3. J’attends la suite avec impatience ! :D
    Merci !

  4. Bonjour !

    Merci pour cet excellent premier article sur REST.
    J’attends impatiemment la suite de la série !

  5. JeBulle.Net » Blog Archive » Qu’est-ce que REST ? - pingback on 15 juin 2011 at 12 h 04 min
  6. Ecrire un client REST en PHP (2/3) | Gerald's Blog - pingback on 16 juin 2011 at 6 h 46 min
  7. le suffixe « ful » ne prend qu’un l => s/RESTfull/RESTful :)

    (comme dans successful par exemple)

  8. Qu’est-ce que REST ? 1/3 | Geralds Blog « Blog José ALVAREZ - pingback on 4 juin 2012 at 14 h 45 min
  9. Merci pour cet article très pédagogique !

  10. Les codes (statuts) HTTP à connaître | Gerald's Blog - pingback on 10 janvier 2013 at 9 h 00 min
  11. Bonjour,

    Merci pour votre article.
    La suite est bien prévue?

    Cordialement.

  12. Une librairie qu je viens de tester est aussi intéressante il s’agit de Gizzle. C’est une sorte de framework REST qui est vraiment pas mal du tout. Je vous la conseille si vous ne souhaitez pas tout faire manuellement.

  13. Je viens de tomber par hasard sur cet article très clair. Je vais parcourir le reste du blog avec beaucoup d’intérêt.

  14. Bonjour,

    Merci. Un article concis et précis, et cela sur plusieurs points ambigus du REST.

    Bon courage pour la suite.

Laisser un commentaire


NOTE - Vous pouvez utiliser les éléments et attributs HTML tags and attributes:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>