Mettre en place un Web Service REST

Problème

Dans une architecture REST classique, un serveur présente les données d’une table et un Client riche (ou RIA) en JavaScript ou un client Mobile permet de les récupérer et des les afficher. REST signifie Representational State Transfer.

Cette architecture permet de réaliser des applications de type onepage en reportant sur le client une bonne partie de la logique métier et en offrant des point d’entrée aux clients pour lire des données sur le serveur ou lui en envoyer.

Ces données pourront être envoyées en XML ou de plus en plus aujourd’hui en JSON : JavaScript Object Notation, c’est à dire des objets directement utilisables en JS.

On pose les définitions suivantes:

  • RIA = Rich Internet Application

  • REST = Representational State Transform

  • Logique métier déportée vers le client

  • Tâche principale du serveur : Offrir des services de récupération et de stockage de données

Un flux de news pourra ainsi offrir par exemple une ressource du type: /api/v1/news/314159 qui permettra aux clients de récupérer la news numéro 314159 en JSON ou en XML en employant la méthode HTTP GET dans la version 1 de notre API. Dans cet exemple, la news est ici la ressource ou élément manipulée dans l’API version 1. La méthode GET sera employée pour récupérer des éléments individuellement ou par Collections.

La méthode POST sera quand à elle employée pour envoyer vers le serveur un ou plusieurs éléments. D’autres méthodes HTTP pour créer ou modifier complètement (PUT) ou partiellement (PATCH) des éléments ou les effacer (DELETE) seront souvent également disponibles dans l’API.

Les technologies concurrentes à REST sont XML-RPC et SOAP (Microsoft) REST est une façon moderne de concevoir ce genre de service et possède les avantages suivants:

  • Bonne montée en charge du serveur

  • Simplicité des serveurs (retour aux sources du protocole HTTP)

  • Equilibrage de charge

  • le serveur offre une API

  • les services sont représentés par des URL’s donc simplicité et bonne gestion du cache

  • Possibilité de décomposer des services complexes en de multiples services plus simples qui communiquent entre eux

Les principes de REST ont été théorisés par Roy Fielding dans sa thèse :

  1. Séparation claire entre Client et Serveur

  2. Le client contient la logique métier, le serveur est sans Etat

  3. Les réponses du serveur peuvent ou non être mises en cache

  4. L’interface doit être simple, bien définie, standardisée

  5. Le système peut avoir plusieurs couches comme des proxys, systèmes de cache, etc

  6. Eventuellement, les clients peuvent télecharger du code du serveur qui s’exécutera dans le contexte du client

Pour mémoire, une API REST peut offrir les méthodes suivantes:

Méthodes HTTP et REST:

Méthode

Rôle

Code retour HTTP

GET URL

Récupération Element

200

GET URL

Récupération Collection

201

POST URL

Envoi d’Elements

201

DELETE URL

Effacer Element(s)

200

PUT URL

Modifier un Element

200

PATCH URL

Modif. partielle d’Elt.

200

Mais on peut aussi avoir des erreurs comme :

Code Erreur

Description

Signification

400

Bad Request

requête mal formée

404

Not Found

Resource demandée inexistante

401

Unauthorized

Authentification necessaire pour accéder à la resource.

405

Method Not Allowed

Méthode interdite pour cette resource.

409

Conflict

Par exemple, un PUT qui crée une ressource 2 fois

500

Internal Server Error

Autres erreurs du serveur.

Par ailleurs, le serveur REST ne maintient pas d’état, les requêtes sont indépendantes les unes des autres. C’est un retour aux fondamentaux du protocole HTTP qui n’est pas doté de beaucoup de capacités de mémorisation …

La logique et l’ergonomie de l’application sont gérées côté client. C’est une méthode aujourd’hui plebiscitée pour faire dialoguer des clients (mobiles ou Web) avec des serveurs.