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

31 réflexions au sujet de « Qu’est-ce que REST ? (1/3) »

    • 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

  1. 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.

      • 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.

  2. Ping : JeBulle.Net » Blog Archive » Qu’est-ce que REST ?

  3. Ping : Ecrire un client REST en PHP (2/3) | Gerald's Blog

  4. Ping : Qu’est-ce que REST ? 1/3 | Geralds Blog « Blog José ALVAREZ

  5. Ping : L’architecture REST expliquée en 5 règles | Le blog de Nicolas Hachet

  6. Ping : Les codes (statuts) HTTP à connaître | Gerald's Blog

  7. Ping : Le protocole OData | JRobaire

  8. Ping : Talend MetaServlet - Blog d'un consultant BI

  9. Ping : Restful api | erizo21

  10. Ping : Les WebService RESTful (REST API) | Benjamin Touchard

  11. 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.

  12. 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.

  13. Ping : Les WebService RESTful (REST API) - Benjamin Touchard

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *