Bonsoir,
au boulot nous gérons deux applications backoffice (généralement orienté crud) et dernièrement il a été envisagé d'adopter une philosophie REST/HATEOAS.
J'avoue que personnellement je me pose quelques questions sur cette approche. :
- peut être est ce la manière dont on me la présenter, ou la manière dont on veut l'appliquer mais j'ai l'impression que dans l'approche qu'on envisage on va méler la présentation et le fonctionnel, je m'explique :
Ce que l'on veut c'est avoir un client sans logique capable de s'adapter à nos changements d'API. Du coup par exemple, si dans mon application de gestion du catalogue des produits, je dois vouloir présenter les menus et sous menus suivants :
"Gestion catalogue produits" >> "Rechercher produit" >> "Créer produit" >> "A propos de l'application"
Je dois fournir l'accès à différentes ressources correspondant à ces entrées de menu... Il me semble que dans ce cas on en arrive à gérer de la présentation depuis l'API, non ?
Ou bien est-ce une erreur de partir sur un "dumb" client ?

- D'autre part avec l'approche HATEOAS, on indique que l'un des buts est d'annuler le couplage client/API; du coup si notre API est diffusé à un client tiers qui a besoin de créer de nouveaux produits, il devra si j'ai bien compris réattaqué avec une url de base d'antrée dans l'API puis naviguer dans celle ci jusqu'à avoir la ressource lui permettant d'ajouter des produits... Il me semble difficile d'arriver à cela. Les tiers avec qui je travailles habituellement utilisent la doc de nos API (anciemment soap) pour appeler le web service permettant d'ajouter de nouveau produits. Si l'API est modifié, il en est informé et doit suivant le cas potentiellement modifié sont code si on a introduit une incompatibilité ascendante...
qu'en pensez-vous ?


Merci de votre retour sur le sujet.