Après un article sur les mashups, il est normal que je me sois intéressé un peu plus au services web dit RESTful.
Qu’est ce qu’un service RESTful, et plus particulièrement l’architecture REST ?
Plutôt que de répondre à la question, voici une selection d’articles :
- RESTful Web Services
- Pour ne plus être en REST, comprendre cette architecture
- How to create a REST protocol
Mais voilà dans tous ce que j’ai pu lire sur REST, quelquechose m’a manqué… J’ai besoin de toucher les choses, il me fallait voir de plus près la Technique. Et je ne suis pas le seul, la question revient souvent dans les commtaires de blogs : “Concretement, si je veux que mon site soit en REST, je fais quoi ?”.
C’est ainsi que j’ai commencé mes recherches sur les différents frameworks disponibles en PHP ou en Java. Je me suis arrêté sur le framework Konstrukt en PHP.
En voici les grands principes, retrouvés dans d’autres frameworks comme Restlet en Java :
1. Une uri = un controlleur.
L’uri ou l’url est l’adresse qui identifie ma ressource. Le controlleur est l’objet qui va traiter ma requête. Il vient du pattern MVC. Chacune de mes requêtes, c’est à dire l’uri demandé, est traitée par un contolleur sélectionné en fonction de celle -ci.
Cas pratique 1 : je suis une agence de voyage, et je souhaite que l’on accède à la liste de tous les aéoports par mon site. Je saisis www.monagence.com/aeroports dans la bar d’adresse de mon navigateur et j’obtiens la liste comme demandé. Nommons le controlleur qui traite ma requête “aeroports_list_controller”.
Cas pratique 2 : je suis toujours mon agence de voyage et je souhaite afficher les détails du vol 816 aux départ d’Orly. Je saisis alors l’url www.monagence.com/aeroports/orly/vols/816. Nommons le controlleur “vols_show_controller” qui affiche les détails du vol 816.
Voila pour le premier Principe.
2. Un controlleur possède deux comportements.
Le premier est celui décrit en 1. Le second est un comportement de routeur. En réalité dans le cas pratique 2 ce n’est pas 1 controlleur qui traite ma requête mais 5. Le premier qui entre en jeu est le controlleur racine “root_controller” qui me redirige vers “aeroports_list_controller”. Pourquoi? Car le premier éléments de mon uri est “aeroports”.
De la même manière “aeroports_list_controller” me redirige vers “aeroport_show_controller” pour traiter “orly”. Enfin en passant par “vols_list_controller”, j’arrive à “vols_show_controller” qui affiche les détails du vol 816 au départ d’Orly.
3. Un controller connaît le contexte dans lequel il est appelé.
Le controlleur “vols_list_controller” est commun à tous les aéroports. Les données mises à disposition par celui sont fonctions de l’aéroport qui l’appelle.
Enfin il ne reste plus qu’a implémenter dans chaque controlleur les méthodes GET, POST, PUT et DELETE de REST.
Voici avec le framework Konstrukt ce que donne le code d’un controlleur :
class components_aeroports_List extends k_Component {
function map($name) {
return 'components_aeroports_Show';
}
function GET() {
global $aeroports;
$this->document->setTitle("aeroports");
$t = new k_Template("templates/aeroports-list.tpl.php");
return $t->render(
$this,
array(
'aeroports' => $aeroports->all()));
}
}
Nous avons donc une fonction map qui permet de rediriger vers le controller aeroports_Show lorsque il y a un éléments dans l’adresse après “aéroports”, ”orly” par exemple. Puis on peut remarquer l’implémentation de la méthode GET faisant appel à un template pour afficher la liste des aéroports.
Pour résumer le schéma général de l’implémentation d’une architecture REST peut se faire avec un pattern Chain of Responsibility. Car finalement c’est pratiquement le pattern que je décris ici.
Comprendre comment était implémenté un des frameworks m’a aidé à mieux comprendre REST. Et c’est comme ca que je me suis confronté à la difficulté de concevoir une architecture orienté ressources plutôt qu’une architecture orienté services.
Mots-clefs : architecture, design pattern, framework, Konstrukt, php, REST, RESTful, web services
