API REST MappedObjectsExternalObject: Remonté d'informations des liens fils

Bonjour,

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

Bonjour,

De quelle mise en place d’API s’agit-il ?

https://docs.simplicite.io/documentation/02-integration/rest-services.md

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

  • avec tous les links de l’objet et des enfants…
  • récursivement en cas de lien réflexif

/api

Il s’agit d’API rest créé via un objet externe avec l’héritage de com.simplicite.webapp.services.RESTMappedObjectsExternalObject

Ce helper ne supporte pas les TreeViews.

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.

La création de ce wrapper a été justifié à l’origine par la volonté d’avoir des API plus “simples” que nos APIs génériques.

Si maintenant ils veulent des treviews, des tableaux croisés , ou autres chose “avancées” il serait donc plus logique d’utiliser les APIs génériques.

PS: Cela dit, de mémoire, le wrapper simplifié permet d’inliner les records liés de 1er niveau

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.

Merci pour votre retour.

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.

Sommes-nous d’accord ?

Oui, c’est bien cela

  1. 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…)
  2. 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…
{
  object: "rootObject",
  userkey: "xyz",
  action : "upsert", // optional (only for POST to insert, upsert, update, delete)
  item: { fields... },
  links: [
     { object: "childObject1", list: [ subobject... ] },
     { object: "childObject2", list: [ subobject... ] },
     ...
  ]
}

où “subobject” a la même structure générique.

Il faut donc voir le message JSON a fournir et la “distance” avec votre modèle.

Si c’est top éloigné de 1 ou 2, il faudra coder un :

  1. Object externe spécifique qui récupère un TreeView et le transforme avant de le retourner.

Autre élément de réflexion, on casse donc le systeme d’un end point part objet, en centralisant sur 1 seul objet ?

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.