Bonjour,
J’expose des données tabulaires (xlsx) mais également dans un JSON avec gros intérêt une hiérarchisation des données.
Pour l’instant seul le flux tabulaire est valorisé / valorisable avec l’API.
Est-il prévu de faire évoluer « l’API-sation » des flux en gérant également les format JSON ? et les format dérivés du JSON comme GeoJSON.
Encore bravo pour l’API-sation !
Bien à vous,
Michel
1 « J'aime »
En aparté, il y a une doc sur comment bien organiser et formater un fichier et ses champs de données pour que l’API marche bien ?
J’ai un peu galéré via la démo pour trouver comment bien faire un CSV et formater les dates.
Et, est-ce qu’il existe un moyen structuré pour documenter les champs d’un fichier de données qui serait exploité par l’API ? Par exemple pour un libellé littéral du nom du champ, une description ou explication, etc.
En tout cas l’outil est très prometteur 
Bonjour,
@mdu : l’APIfication des fichiers JSON n’est pas prévue pour l’instant. La distribution de données arboresentes semble a priori beaucoup plus complexe : là où pour les données tabulaires chaque item est une ligne, avec possibilité de filtrer les colonnes, qu’en serait-il d’un fichier avec plusieurs niveaux ? L’idée de cette API est qu’elle soit la plus agnostique possible, il nous serait donc compliqué de rentrer dans les détails de chaque fichier JSON pour déterminer (automatiquement) comment en exposer le contenu.
@oliezekat : la librairie utilisée par notre script pour détecter les types se veut également la plus agnostique possible. Vous pouvez vous baser sur notre guide qualité, mais normalement, hors formats très alambiqués, nous devrions pouvoir détecter le type correctement. Nous n’avons pour l’instant pas de moyen d’intégrer une documentation custom dans pour une ressource APIfiée, le meilleur moyen de procéder étant de publier la documentation comme fichier dans le jeu de données, afin qu’elle soit visible pour les utilisateurs au plus près du fichier qu’elle documente.
1 « J'aime »
Bonjour,
Je ne sais pas du tout comment se déroule le procédé « d’API-sation » des données mais peut-être quelques idées de pistes techniques (mon vocabulaire n’est peut-être pas correct, je m’en excuse par avance) :
1/ avec les fonctions intégrées dans les BD : avec Oracle et PostGreSQL (et probablement aussi MariaDB et d’autres) on a la possibilité d’avoir un champ au format JSON. Ces champs peuvent être lus par requête SQL et sélection sur les clés, mais également lorsque la base de données et la table sont « API-sés » (avec Oracle et PostGre c’est dans les outils « de base de la base ») on peut faire des requêtes dessus par WS. En gros on pourrait charger tous les JSON dans une table avec 3-4 champs : un champ avec le nom du fichier, un champ date màj, un champ producteur, et la ligne JSON. C’est peut-être une piste à essayer ?
2/ une autre piste (plus propre mais plus contraignante) serait que pour activer cette fonctionnalité celui qui publie les données dépose également un fichier de description du JSON au format JSON-P ou YAML ?
Mais bon, déjà « l’API-sation » du tabulaire c’est une super-avancée et un super service,
Question peut-être préalable : est-ce qu’il y a beaucoup de fichiers JSON (ou XML) de publiés ou ça reste exceptionnel sur la plateforme ? En effet si en plus les fichiers JSON ça reste rare le sujet n’en vaut alors pas la peine.
Bien cordialement, bonne continuation,
Michel
PS.
Comme les liens vers les fichiers sont stables (c’est vraiment super ça) cela permet d’avoir un batch avec un ftp qui récupère en cas de mise à jour. Et du coup l’opération décrite ci-dessus… en fait pas compliqué de la réaliser dans sa propre BD 
.