get JSON dessin de fichier DDI

[dzkwsk]

créer un service DDI AS, pour récupérer les métadonnées du dessin de fichier, (datarelationship) , à partir d'un uuid a priori, et retourner le JSON .

la transformation XSLT est celle jointe.

[EmmanuelDemey]

GET /ddi-as-to-json/:uuid

Avec éventuellement le fichier xslt en body de la requête

[dzkwsk]

DDI_Datarelationship_to_JSON.txt

[FBibonne]

@dzkwsk Est-ce que tu pourrais fournir un scénario de test ( Xml en entrée et données attendues en sortie ) ?

[dzkwsk]

sortie_JSON_5c_1609.JSON
physical_instance_indiv_xml.txt

Si c'est ok ce serait pas mal de faire un test ensuite avec un XML volumineux. La création du JSON d'un fichier avec plusieurs listes geo étaient hyper long sur un poste Insee. peut être que sur serveur ça sera transparent.

[FBibonne]

Ok. je vais les prendre en compte.

@dzkwsk j'ai également deux questions sur les endpoints : je m'interroge sur la formulation des enpoints : d'un point de vue API, la pourrait dire que la ressource mobilisée par les endpoints est un transformer ou bien un derefencer. L'appel à l'API en lui même ni ne crée ni ne modifie la ressource. Donc le verbe utilisé pour moi devrait plutôt être un GET. Par exemple GET /ddi/transformToJson : qu'en dis-tu ? Est-ce que le POST est une contrainte de votre côté ?

Autre question également : c'est vraiment un besoin de votre côté d'envoyer le DDI dans un fichier avec la requête ou bien, on pourrait mettre le contenu du fichier dans un simple paramètre du corps de la requête ?

[dzkwsk]

@FBibonne comme on avait échangé en sprint mais sans revenir dessus depuis, il s'agit bien d'un GET, donc de faire une requête à partir d'un uuid en paramètre de le requête et donc on n'a aucun besoin d'avoir le DDI en paramètre dans un fichier (comme c'est en revanche le cas pour la méthode codebook). Le DDI XML sur lequel la transfo XSLT est appliquée devrait être un objet intermédiaire récupéré et transformé dans l'exécution de cette méthode et de pouvoir obtenir en sortie un JSON dont le modèle est joint à la conversation

[FBibonne]

@dzkwsk
J'essaie d'avancer sur le sujet mais l'état du code de DDI-AS est mauvais et j'ai d'importants travaux de refactor à mener dedans. Je pense que je pourrai fournir une première version fin décembre. J'espère que ça ira.

Désolé mais je ne m'étais pas rendu compte de l'ampleur de la tâche

[dzkwsk]

Ok, fin décembre ça marche, on peut poquer à la main en attendant, il y aura a coup sûr une nouvelle version de la transfo xslt avec des ajouts à la marge suite à des échanges récents avec l'upod. Si on fait une v1 de la méthode et qu'après on intègre les évolutions à la marge dans une autre carte est ce que ça te semble ok ? Les évolutions c'est du style, ajouter une propriété version , ou renommer un élément , je préférerai que tous ces changements mineurs soient consolidés pour faire une nouvelle carte, sachant que le gros du boulot c'est surtout le travail de refactorisation j'imagine. Le lun. 25 nov. 2024, 19:13, Fabrice Bibonne ***@***.***> a écrit :

…

@dzkwsk <https://github.com/dzkwsk> J'essaie d'avancer sur le sujet mais l'état du code de DDI-AS est mauvais et j'ai d'importants travaux de refactor à mener dedans. Je pense que je pourrai fournir une première version fin décembre. J'espère que ça ira. Désolé mais je ne m'étais pas rendu compte de l'ampleur — Reply to this email directly, view it on GitHub <#93 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AK7RGUFWPTLKDVT4DRW2CNT2CNSGPAVCNFSM6AAAAABNHW7FFKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIOJYG4ZDAMJYHA> . You are receiving this because you were mentioned.Message ID: ***@***.***>