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 :
Séparation claire entre Client et Serveur
Le client contient la logique métier, le serveur est sans Etat
Les réponses du serveur peuvent ou non être mises en cache
L’interface doit être simple, bien définie, standardisée
Le système peut avoir plusieurs couches comme des proxys, systèmes de cache, etc
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.