changer les urls de requête dans CIS_front

[CBalsier]

partie Vue.js

Dans frontend/scripts/cisProjectSearchAPI.js

• [ ] remplacer URL racine
• [ ] /api/infos?only_spiders_list=true : liste des spiders/sources avec nom/nom complet/id/logo (linké depuis leurs sites ?) :arrow_right:
• [ ] /api/data?token=pwa&results_per_page=100000 : données brutes :arrow_right:
• [ ] /api/data?page_n=${page}&results_per_page=${per_page}&token=test_token&shuffle_seed=${shuffle_seed}${searchArg}${spiderArg}${tagsArg} : données brutes avec paramétrage utilisateur :arrow_right:

partie Flask

Dans templates/new-home.html et new-home-english.html

• [ ] /api/infos : pour le nombre de projets qui s’affiche sous la barre de recherche :arrow_right:

Dans templates/qui-fait-quoi.html

• [ ] /api/infos?only_spiders_list=true : liste des spiders/sources (cf. plus haut) cf #313

[CBalsier]

Pour la partie "afficher le nombre de projets sous la barre de recherche", de ce que je comprends :

• il n’y a pas de champ/résultat dédié dans l’API prj/infos/get_one/prj_id,

• par contre cette requête renvoie les identifiants des datasets d’input et d’output (dsi et dso),

• de là je peux requêter les infos sur les datasets (via dsi/infos/get_one/dsi_id ou dso/infos/get_one/dso_id), récupérer les f_data_count et sommer pour avoir le nombre total

• intuitivement, il faudrait prendre les datasets traités (dso ?) pour avoir les données consolidées, mais dans le cas présent, pour le projet APCIS - données, il n’y a pas encore de dso, seulement un dsi (l’export d’OpenScraper, si je suis bien)

• est-ce que c’est pertinent de réfléchir/mettre en place un algo du type :

  • requêter le projet pour récupérer les identifiants de datasets
  • s’il y a un/plusieurs dso : sommer les f_data_count pour avoir le nombre total (est-il normal/envisageable d’avoir plusieurs dso ? doit-on en préférer un ? sur quelle base ? comment gérer les gens qui exporteraient plusieurs fois leurs infos mais avec différents critères, donc pas forcément le même nombre de lignes ?)
  • s’il n’y a que un/des dsi : est-ce qu’on somme les f_data_count (agrégation de plusieurs sources) ? est-ce qu’on garde seulement le max des f_data_count ("j’essaie de compléter mon gros fichier par des fichiers parcellaires") ? seulement le min ("je veux garder seulement les données qui sont suffisamment précises parce qu’elles apparaissent dans deux fichiers donc je peux agréger comme il faut") ?

• ou est-ce qu’on met bêtement en dur dans le script de la page d’accueil la requête vers les infos d’un dataset précis ? (dans ce cas, comment gérer de potentielles évolutions ?)

ping @JulienParis (et dans une moindre mesure @Eliselalique) pour plus d’infos/idées/avis

[CBalsier]

Pour la partie /api/data?token=pwa&results_per_page=100000 : données brutes :

• cet appel sert en fait à récupérer les données d’un seul projet CIS (un élément de data pour Solidata, puisque les projets Solidata ne correspondent pas à la même chose) via la fonction getProjectById(id)
• juste avant la définition de cette fonction, il y a deux lignes commentées // This function is super-inefficient // TODO Create a server-side end-point to get only one project (la fonction demande toutes les données, pour ensuite les parcourir jusqu’à trouver celui qui porte le bonne ID)
• est-ce que cet endpoint spécifique existe désormais dans Solidata ? je n’ai pas trouvé d’endpoint plus granulaire que dsi/dso
• s’il n’existe pas, pour retrouver les infos d’un seul projet, il faudrait requêter le projet APCIS, puis requêter et parcourir les dso (s’ils existent ?) ou dsi ? ce qui ne serait pas beaucoup plus efficace, mais pourrait faire l’affaire dans un premier temps ?
• il y a un paramètre item_id pour les requêtes dsi/infos/get_one/dsi_id (idem pour dso), mais ces requêtes produisent une erreur serveur (500), depuis le JS et l’interface de "bac à sable" de la doc
• reste le problème de parcourir les dsi/dso pour trouver le bon

[CBalsier]

Pour la partie /api/infos?only_spiders_list=true (qui se retrouve dans templates/qui-sommes-nous.html et dans frontend/cisProjectSearchAPI.js

• dans le js, c’est la fonction getSpiders qui fait appel à un paramètre d’API only_spiders_list=true d’OpenScraper
• dans le template, le même paramètre est utilisé
• dans le js, la fonction est précédée de // This function is awkward // TODO Create a dedicated server-side end-point to get only the spiders :arrow_right: qu’en est-il sur Solidata ?

[CBalsier]

Correspondances entre les API CIS-OpenScraper et Solidata :

• api/data et api/dsi/infos/get_one/dsi_id

Contenu	CIS-OpenScraper	Solidata
Données des projets CIS	query_results [{	data {data_raw {f_data[{
Champs disponibles pour les données	fields_open_level{fields_returned[{	data{data_raw{f_col_headers[{ + interroger dmf si besoin
Liste des spiders	spiders_dict[{	?
Détails	query_log{	data{infos, log, public_auth, specs + query + query{query_args
Message	−	msg
Nombre de projets	par api/infos/ : counts.data	data{f_data_count
Sous-datasets	−	data{datasets{

• détails des paramètres pour les… détails (à finir)

Contenu	CIS-OpenScraper	Solidata
N° de page	query_log{query{page_n et/ou query_log{page_n (valeurs différentes ?)	query{page_args{page + query_args{page
N° dernière page	query_log{page_n_max	?
Nbre de résultats/page	query_log{query{results_per_page	per_page
Mot-clé recherché	search_for (tableau !)	search_for (string)
Tri	query_log{query{sort_by	query{query_args{sort_by
Seed	query_log{query{shuffle_seed	query{query_arg{shuffle_seed
ID	query_log{query{item_id	query{query_arg{item_id