Notes d'architecture

Paradigme REST

Note prise a partir de la fiche Wikipedia

• client / serveur : le serveur se charge d'exposer les moyens de modifier les données via une api, le client se charge de les présenter ou de procéder à des cacluls sur ces données. Le cycle de vie du client peut ainsi être différent de celui du serveur.
• serveur sans état : chaque requete du client contient toutes les informations nécessaires pour procéder à l'action demandée. Pour cela il ne devrait y avoir besoinde de dépendre d'un état antérieure à la demande.
• avec cache : cheque reponse du serveur contient des informations sur le fait que les informations transmises peuvent être mise en cache en toute sécurité. Les iniforations mises en cache ne devraient pas poser de problèmees si elles sont resoumises telles quelles au serveur. Cette mise en cache permet d'accroitre les performances de la solution
• interface uniforme : chaque ressource possède une id
• les ressouces ont des repreentation définies
• les messages portent des meta info (portées par le protocole) qui decrivent de façon complètee les info (encodage, dates etc.. )
• hypermedia : chaque accés aux état suivants de l'application sont présentes dans le message courant.

Reflexions sur le protocole REST

Notes issues de la page intéressante

Scénario de création

appel de /new -> affichage d'un formulaire -> soumission du formulaire à l'url /create

Scénario de mise à jour

appel de /edit/id -> affichage d'un formulaire contenant les informations de l'item demandé (id)-> soumission du formulaire à l'url /update

Reflexion sur l'architecture FrontOffice / BackOffice / Api Commune

Le lien ci contre contient une discussion intéressante sur la manière de mettre en place plusieurs applications dans un projet Symfony. Cette manière ce base sur la notion d'environnement de Symfony : chaque environnement peut charger la classe Kernel de son choix, chaque Kernel spécifiant son lot de bundle à charger.

Reflexions sur le niveau d'hypermediation de l'api

Afin d'être compatible aux principes HATEOAS.

Vu que l'application Doc-Depot a pour vocation a être open source, on pourrait imaginer qu'elle porte une amibtion moderne sur son interopérabilité. Ainsi elle pourrait supporter toute la spécification HAL Définition , ainsi qu'un article.

Le HAL a pou avantage de décrire les actions possibles a chaque reponse du serveur de l'API. Ainsi, il est possible pour un client de découvrir de nouvelles fonctionnalités ou d'être dirigé en toute sécurité vers une ressources qui auraitn été déplacée.

Ainsi HAL apparit comme quasi incontournable pour toute API dans le cycle de développement est très vivant et qui a besoin de garantir à ses clients une continuité fontionnelle.

Cependant, cette intégration a un cout et amènerait de possibles risques :

• on adopte un plugin qui support le HAL, mais il s'avère que le plugin n'est pas aussi facile à utiliser ou configurer : on pert en efficacité et des contributeurs pourraient être lassés de son utilisation pour le dev de la solution
• la spécification est toujours en cours de travail
• on ignore quelle est la véritable adoption du protocole.
• la taille de l'api de doc-depot est elle suffisante pour qu'une service auto-descriptif soit nécessaire pour de futurs branchements avec d'autre SI

:exclamation: Au regard de tout ceci, la mise en place de HAL ne trouverait pas de bénéficies pésant suffisament dans la balance pour rentabiliser les cout inhérents aux risques .