Nous avons une demande client sur la conception d’API que je souhaite me faire confirmer.
La question est la suivante : Lors de la mise en place des API sur un objet, est-il possible (en restant dans les standards de développement des API) d’avoir les lien fils, petit fils etc … ?
Actuellement, nous remontons les liens fils (avec les plus ou moins d’information en fonction de ce que l’on souhaite exposer),.
Merci d’avance pour votre retour.
Jean-Baptiste BLANC
Pour exposer une hiérarchie d’objets, il faut passer par un TreeView qui peut s’afficher sur la UI mais aussi servir en GET en lecture (depuis un objet racine) + POST pour mise à jour (avec des actions upsert, update, delete…à indiquer sur les objets de l’arbre).
Exemple sur TreeUser : qui ramène le user, ses paramètres, ses droits… La réponse JSON est un arbre
Et je ne pense pas que les Links soient récursifs. La question est plus pour @david qui a conçu cette interface RESTMappedObjectsExternalObject, à l’origine pour faire du CRUD sur un objet mappé avec des nommages différents.
Il faudrait pouvoir y ajouter un Link à un Link pour permettre de mapper toute une hiérarchie.
A date c’est l’appelant qui devra faire les appels récursifs parent/enfants car le mapper supporte qu’un seul niveau de Link.
Oui le Link permet donc de boucler côté client pour chercher des enfants en profondeur.
Une évolution serait de gérer un “addLinkToLink” pour gérer la hiérarchie, ça ne devrait pas être trop compliqué.
Mais au final on va réinventer le Treeview… si l’objectif est d’exposer un arbre avec des noms d’objest/fields différents, ça revient également à créer des Objets dédiés pour les API et à les utiliser dans un TreeView standard.
Je souhaite juste apporter un réponse sur ce que propose actuellement l’outil.
Je comprends donc qu’actuellement ce n’est pas possible avec ce wrapper, et qu’il faudrait une évolution du socle Simplicité pour le permettre (soumis à votre validation notamment quant à la pertinence de la request).
Vos API génériques pourraient correspondre à ce besoin.
Le wrapper ne gère qu’un seul niveau de lien, passer à plusieurs reste à étudier surtout vis à vis du format de sortie attendu (un Link n’est pas forcement une simple jointure, virtual link, reflexif…)
Le Treeview répond déjà au besoin mais avec une structure imposée, il sait gérer les reflexives et les liens virtuels, les “canReference”, postLoad, search-spec sur des instances dédiées…