La boîte à prog

 Il y a une multitude de question quand nous commencons à convevoir un API rest. Un débat qui reviens souvent est les ressources imbriqués, parent / enfant, sous-ressource. Hierachie Pourquoi opter pour /parents/{idParent}/enfants/{idEnfant} au lieu de  /enfants/{idEnfant}   La première approche peut être préférable si on veut montrer le lien hierarchique qui unit les ressources. Il faut cependant ne pas exagérer du niveau hierachique, car l'url peut rapidement devenir très long et rendre le tout moins lisible. Il est d'ailleurs rare de voir un api avec plus de 2 niveau. Dans le deuxième cas, pour une sauvegarde, il faudrait que la ressource est le nom du parent. Une autre approche serait /parents/{idParent}?enfants={idEnfant}   Doublon   Rien n'empêche d'utilisé plusieurs approches, dans ce cas, on pourrait se retrouver dans le cas qu'il y a différent endpoint pour obtenir la même ressource.   Longueur des url /companies/{idCompany}/departments/{idDepartm...

 Vous avez un ensemble d'api qui est utilisé par de multiple clients. De nouvelle fonctionnalités prévue vont changer les valeurs de retour et les paramètres de certaines méthode. Afin de ne pas casser l'existant, il est possible de mettre en place plusieurs versions des apis. Nous verrons différentes approche pour mettre en place le versionnement d'un api. Versionnement des entités, payload Dans la première mise en place d'un api vous avez une entité  Person Si vous devez ajouter un nouveau champs dans cette entité, l'ancienne pourrait être renommé PersonV1 et la nouvelle PersonV2. PersonV2 ayan un champ prenom Versionnement des url @RestController public class PersonController { @GetMapping("v1/person") public PersonV1 personV1() { return new PersonV1 ("Collin"); } @GetMapping("v2/ person ") public PersonV2 personV2 () { return new PersonV2 ("Collin", "Marc"); } }     Versionnement par un Req...