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¶metre=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.

    • REST / RESTFull => Même combat 🙂

      • Euh ben non, lire mon post ci-dessous.
        Du moins si on veut être clair et précis sur les termes…
        A noter que nombre des avantages d’une architecture RESTFul disparaissent si on realise en fait une architecture hybride REST-RPC.
        Je vous renvoie à la literature sur le sujet, comme « RESTFul web services cookbook », ou « RESTFul web services ».

        • J’avoue humblement ne pas avoir lu la thèse de Roy Fielding dont est issu REST.

          Toutefois, je persiste pour dire que REST et RESTful sont globalement synonymes.

          Pour alléger le débat, je vais citer le livre de Richardson que vous citez (que j’ai eu plaisir à ressortir)

          The traditional definition of REST leaves a lot of open space, which practitioners have seeded with folklore […]

          “REST” is a term used in religious nerd wars.

          When it’s used, the implication is usually that there is one true RESTful architecture and it’s the one the speaker prefers. People who prefer another RESTful architecture disagree. The REST community fragments, despite a general agreement on basic things like the value of URIs and HTTP.

          Le seul propos du billet présent est de vulgariser un type d’architecture, et je pense qu’il fait correctement son travail sur cet aspect 🙂

          Dans le cadre de mon exemple, on peut supposer que mon système dispose d’un endpoint qui accepte des « Demandes Client » (je vous demande de supprimer un article de ma commande de fourniture de bureau). Ainsi, un POST sur une ressource « DemandeClient » peut tout à fait avoir pour effet de supprimer un article d’une commande existante et être (selon moi) considéré comme RESTful.

  3. J’attends la suite avec impatience ! 😀
    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.

  15. Le protocole OData | JRobaire - pingback on 10 avril 2015 at 13 h 23 min
  16. Talend MetaServlet - Blog d'un consultant BI - pingback on 15 juin 2015 at 20 h 22 min
  17. Bonjour,

    Merci encore pour cet article très précis.
    Qu’en est il de la suite ? 🙂
    Merci et bon courage,

  18. Restful api | erizo21 - pingback on 27 novembre 2015 at 17 h 08 min
  19. Les WebService RESTful (REST API) | Benjamin Touchard - pingback on 1 juillet 2016 at 1 h 06 min
  20. Trois remarques vite fait :
    1) à proprement parler, REST ne repose pas sur HTTP. REST est un style d’architecture distribuée indépendante du protocole. Le fait qu’en pratique ce soit toujours HTTP qui soit utilisé n’enlève rien au fait que R.Fielding a décrit ce style d’architecture sans adherence à HTTP. Références : voir les commentaires de R.Fielding sur le sujet.
    2) dire que REST = RESTFul est abusif. On parle d’architecture RESTFul quand les principes de l’architecture REST (interface uniforme, HATEOAS, serveur sanbs état, etc.) sont tous respectés par l’architecture ainsi qualifée. Si ce n’est pas le cas, on parle d’architecture hybride REST-RPC (les plus courantes, de très loin). Référence : « RESTFul web services », de Richardson et Ruby
    3) dans le cas de HTTP, la création d’une resource ne passe pas forcément par la méthode PUT, comme suggéré par le début de cet article. Cela dépend en fait de qui décide du nommage de la resource (son URI) : le client (utilization de PUT) ou le serveur (utilisation de POST). Dans le cas de l’exemple (un livre d’une bibliothèque), si un outil client est utilisé pour ajouter un nouveau livre, le PUT sera adapté. Ca pourrait nre pas être le cas dans un autre contexte (par exemple, si on utilisateur externe pouvait ajouter un livra à la bibliothèque – meme si ce cas de figure semble peu plausible dans le cas d’une bibliothèque). Par contre, créer un item dans un blog passe logiquement par un POST (on appelle d’ailleurs ça un post 🙂
    Notez bien que cette distinction n’est pas rhétorique, car un PUT est idempotent, amors qu’un POST ne l’est pas (à cause du choix de l’URI, justement), ce qui peut entrainer des consequences dans une architecture Web réelle (i.e. avec proxies qui pouraient éventuellement se charger de gérer la relance d’une requête non aboutie).
    Références : la RFC 2616, et « RESTFul web services », de Richardson et Ruby

    • Pour le point 1 et 2, j’ai pris en effet quelques racourcis dans l’article (qui date un peu).

      Pour le point 3, je ne crois pas (même après relecture en diagonale) avoir indiqué que PUT était préféré pour la création, mais au contraire indiqué que c’était POST qu’il fallait privilégier dans la majorité des cas.

      En tous les cas merci d’avoir commenté et apporté ces précisions sur le billet.

  21. Bon, il y aurait pas mal d’autres remarques à faire et de confusions à clarifier dans cet article, juste un mot sur SOAP.
    La difference de base entre SOAP et REST, c’est qu’une architecture REST sur HTTP utilise HTTP en tant que protocole applicatif, alors que SOAP l’utilise comme protocole de transport uniquement.
    Du coup, SOAP doit ajouter des choses, au travers de l’enveloppe SOAP typiquement, alors que REST sur HTTP utilise ce que fournit déjà HTTP. SOAP plaque en fait sa vision « RPC » des choses sur le monde HTTP. Et l’utilisation unique du POST pour les requêtes SOAP est une hérésie dans le monde du Web.
    Le fait que l’outillage SOAP permette de générer des choses (comme les stubs et skelettons, pour parler façon CORBA) n’est pas vraiment un avantage, car en REST, on n’a pas besoin de stubs et de skelettons, justement…
    A côté de ça, SOAP présente un avantage en matière de sécurité, car il fournit en « standard » WS-Security, qui assure par exemple le chiffrement de bout en bout, à la différence de ce que permet de faire HTTPS pour une appli REST.
    Mais bon, c’est un autre et très vaste sujet…

    • Je viens de relire la partie Soap vs Rest. Oui, je suis d’accord avec vous pour dire que l’explication est assez approximative 🙂

      Pour l’histoire de l’enveloppe SOAP, j’avais choisi de laisser de coté son utilité car cela ne servait finalement pas le propos de l’apparté qui visait simplement à dire que REST-like était souvent plus facile à mettre en oeuvre que SOAP.

      Encore une fois, merci pour vos compléments.

    • En seconde lecture, j’ai toutefois envie de soutenir que les WSDL sont pratiques dans le cadre d’échanges avec des tiers car ils formalisent certains aspects des contrats de service (paramètres obligatoire, format de réponse, …).

      A titre d’example, cet élément étant manquant coté REST, il nous a parfois fallu générer des WADL pour permettre la consommation de services par des logiciels tiers (dont nous n’avons pas la maîtrise) . Si nous avions choisi SOAP pour ces cas précis, les éléments auraient déjà été présents.

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=""> <s> <strike> <strong>

Trackbacks and Pingbacks: