API v2 /path

[mchourot]

Bonjour,

J'ai fait un test avec la méthode path de l'api v2 car je souhaitais récupérer les tronçons de certains réseaux de manière automatisée et j'ai constaté:

• que le paramètre url retourné renvoyait vers les itinéraires (trek au lieu de path mais cela est peut-être lié à la version de geotrek)
• qu'il manquait l'information des types de réseaux associés au tronçon. Cette possibilité n'est ni dans les paramètres d'interrogation, ni dans les données alors qu'il y a un nœud qui contient le commentaire qui n'a, à mon sens, qu'un intérêt mineur. Cela rend cette méthode quasiment inutile à part si quelqu'un souhaite récupérer l'intégralité des tronçons de manière brute et non qualifiée. Serait-il envisageable de rajouter cette information au moins dans les données de retour ?

Merci d'avance

[camillemonchicourt]

Je viens de tester la route /path de l'API de Geotrek-admin sur notre serveur de démo : https://geotrekdemo.ecrins-parcnational.fr/api/v2/path/?page_size=10 (admin / admin).

C'est la seule route de l'API en lecture qui est protégée par authentification.
En effet la propriété "url" a un soucis dans sa définition et on n'a pas ajouté tous les champs dans cette route qui n'a actuellement pas d'usage défini.
En effet cela serait intéressant de corriger et compléter cette route.

[babastienne]

La release 2.99.0 permet d'ajouter dans l'API les informations suivantes :

• Arrival
• Comfort
• Departure
• Networks
• Source
• Stake
• Usages

Problème, pour les champs source, comfort, stake et usages on renvoi un id mais à aucun moment dans l'API V2 on ne donne la possibilité de trouver la correspondance entre cet ID et la valeur associée.

Il faut décider si soit :

• Pour chacun des 4 types d'objets cité on ajoute une nouvelle route d'API qui permet d'obtenir les détails. Dans ce cas faut-il authentifier ces nouveaux endpoints comme pour path ?
• On ajoute le détail de ces objets directement dans le endpoint path

Un avis @camillemonchicourt ou @submarcos ?

Le release permet aussi de corriger l'URL qui renvoyait jusqu'alors vers les itinéraires, le problème est résolu.

[camillemonchicourt]

Pour être cohérent avec le reste de l'API v2, il faudrait plutôt uniquement renvoyer l'ID et avoir une route pour chaque objet lié avec son ID et son LABEL. Donc path_source, path_comfort...
Mais ça a souvent été discuté car cela rend l'utilisation de l'API plus complexe, en faisant des jointures comme dans une BDD, alors que ce n'est pas l'usage habituel d'une API.

Mais par cohérence avec le reste, je resterai sur ce fonctionnement.

Et rediscuter cela globalement pour une V3 de l'API où les infos liées seraient remises à plat dans chaque route, pour ne pas avoir à faire des "jointures".