Élements de données : L’essence de l’architecture REST
Il est très fréquent de lire sur le web des assimilations de REST (Representational State Transfer) à un protocole simplifié qui se limite a généraliser les opérations a exécuter sur une donnée. Ainsi nous voyons les GET POST PUT DELETE et les spécifications du protocole http qui forment la base de l’architecture web être exposées comme étant tout ce que REST ajoute.
Par ailleurs, la philosophie de ce style est bien plus intéressante, Ce dernier est en fait une abstraction des éléments d’architecture et un système d’hypermédia distribué. REST ignore les détails d’implémentation des composants ainsi que la syntaxe du protocole et se concentre sur les rôles des composants, les contraintes liées à leur interaction avec d’autres composants ainsi que leur interprétation des éléments de données significatives. Les contraintes fondamentales sont en effet englobées dans les composants, connecteurs et les données qui définissent les bases de l’architecture Web et forment l’essence de son comportement comme une application réseau.
Les éléments de données
À la différence du style d’objets distribuées, où toutes les données sont encapsulées par les composants de traitement, la nature et l’état des éléments de données d’architecture de REST est un aspect clé de REST. La raison derrière cette conception émane de la nature du système Hypermédia. Lorsqu’un lien est sélectionné, l’information est transférée de son emplacement ou elle est stockée a l’emplacement ou elle va être utilisée (dans la majorité des cas, un lecteur humain). Ceci est diffèrent de beaucoup d’autres paradigmes ou il est possible, et souvent préférable, de déplacer l’agent de traitement (code mobile, procédure stockée etc.) a la donnée que de déplacer la donnée au processeur.
Un architecte Hypermédia a uniquement trois options fondamentales :
- Client Serveur Traditionnel : interpréter la donnée directement dans leur emplacement et envoyer une image a format fixe au destinataire
- Style Objet : encapsuler la donnée avec un engin de traitement et envoyer l’ensemble au destinataire
- Données brutes : envoyer la donnée brute avec de la méta data qui décrit le type de la donnée pour permettre au destinataire de choisir son propre engin de traitement
Chaque option a des avantages et des Inconvénients :
| Option | Avantages | Inconvénients |
|---|---|---|
| Client Serveur Traditionnel | Cache la vraie nature de la donnée au récepteur afin de prévenir toute assomption sur la structure de ces dernières et rend l’implémentation plus facile au client | Restreint sévèrement les fonctionnalités du récepteur et place la majorité du traitement sur le serveur, ce qui mène a des problèmes d’évolutivité |
| Style Objet | Protège la donnée en offrant un traitement spécialisé via son unique engin | limite la fonctionnalité du client à ce qui a été anticipé par l’engin et peut augmenter considérablement la taille de la donnée transférée |
| Données brutes | Permet au serveur de rester simple et évolutif en minimisant les octets transférées. | Pert les avantages de l’encapsulation de données et nécessite que les deux interlocuteurs serveur et client comprennent les mêmes types de données |
REST fournit une approche hybride de ces trois options en se concentrant sur la compréhension partagée des types de données, tout en limitant la portée de ce qui est exposée a une interface standardisée. Les composants de REST communiquent en transférant une représentation d’une ressource dans un format qui correspondant a un ensemble de types de données standards, sélectionnées selon les désirs et / ou capacités du client et la nature de la ressource. La donnée reste cachée derrière l’interface, la représentation quand a elle, peut être au même format que la donnée ou différente.
Les avantages du style objet mobile sont approchées en envoyant une représentation qui consiste en des instructions dans un format de donnée standard d’un engin de traitement encapsule.
REST permet donc la “séparation des préoccupations” (Séparation of Concerns) du style client-serveur en éliminant le problème de l’évolutivité du serveur, en assurant le masquage d’informations par le biais d’une interface générique pour permettre l’encapsulation et l’évolution des services et en prévoyant un ensemble diversifié de fonctionnalités grâce à des moteurs téléchargeables.
Dans le post prochain, j’aborderai la notion des “Eléments de l’architecture REST”, en l’occurrence : ressource, identifiant de ressource, représentation, méta données de représentation, méta données de ressources et données de contrôle.
