Faire évoluer l'API de code.gouv.fr

[hjonin]

• Décrire les points d'API et les modèles de données actuels (si pas déjà fait)
• Pour repos.json :
  • Expliciter les noms des champs dans les réponses
  • Pour les champs existants :
  • name : à garder dans la réponse
  • organization_name : à garder ou à déduire de l'url ?
  • platform : à supprimer de la réponse
  • repository_url : à garder
  • description : à garder
  • is_fork : à garder si applicable sur d'autres plateformes que github
  • is_archived : à garder tel quel ou à fusionner avec un champ is_empty dans un nouveau champ is_experimental
  • last_update : à garder
  • stars_count : à garder (quand applicable)
  • forks_count : à supprimer car seulement sur github ?
  • license : à garder
  • language : à garder
  • is_esr : comment est-il calculé ?
  • is_lib : à supprimer (cf. type)
  • is_contrib : à supprimer
  • is_publiccode : à compléter avec d'autres fichiers (par exemple README, CONTRIBUTING) ?
  • reuses : à supprimer
  • Ajouter des champs :
  • id ?
  • administrations (champ multiple)
  • version ou latest_release ou latest_tag
  • vitality dont la valeur est calculée à partir de TBD (cf. https://github.com/italia/publiccode-crawler/blob/main/vitality-ranges.yml)
  • status dont la valeur (Concept, Alpha, Beta, RC, Stable) est calculée à partir du numéro de version (cf. SemVer) : à calculer côté back ou front ?
  • type dont la valeur correspond à TBD (champ multiple) : ce champ peut-il être déduit automatiquement ou rempli par l'utilisateur dans la future BDD ? Oui pour les lib, quid des autres types (logiciels, API, algos, etc.) ?
  • sill_id : ce champ doit-il être rempli automatiquement côté back ou front ?
  • homepage
  • topics
  • software_heritage_url
  • Compresser la réponse (si pas déjà fait) : de manière générale, il faudra surveiller la taille de la réponse après ces modifications et peut-être agir en conséquence (pagination ?)
• Créer les points d'API pour récupérer les valeurs des filtres : côté back ou front ?
  • Administrations
  • Catégories (topics)
  • Types
  • Langages
  • Licences
  • Organisations : revoir le lien avec les administrations (1 orga, n admins)
  • Dépendances
• Revoir le point d'API stats

[bzg]

status dont la valeur (Concept, Alpha, Beta, RC, Stable) est calculée à partir du numéro de version (cf. SemVer)

Est-ce qu'il y a une correspondance standard calculable pour déduire [Concept|Alpha|Beta|RC|Stable] depuis le numéro de version ?

D'instinct je suis un peu sceptique sur une automatisation ici, mais de la doc m'intéresse.

[bzg]

Décrire les points d'API et les modèles de données actuels

Les schémas de données sont ici :

https://git.sr.ht/~codegouvfr/codegouvfr-fetch-data/tree/master/schemas/

Mais ces descriptions peuvent être mises plus en avant.

[bzg]

Merci pour tous ces éléments !

[hjonin]

status dont la valeur (Concept, Alpha, Beta, RC, Stable) est calculée à partir du numéro de version (cf. SemVer) Est-ce qu'il y a une correspondance standard calculable pour déduire [Concept|Alpha|Beta|RC|Stable] depuis le numéro de version ? D'instinct je suis un peu sceptique sur une automatisation ici, mais de la doc m'intéresse.

Normalement oui, on devrait pouvoir extraire avec une regexp le type de version de pré-release (Alpha, Beta, RC) après le tiret (https://semver.org/#spec-item-9). Concept serait un code source sans version et Stable une version stable.

Moyennant bien sûr que le code source suive cette sémantique :)

[hjonin]

Décrire les points d'API et les modèles de données actuels Les schémas de données sont ici : https://git.sr.ht/~codegouvfr/codegouvfr-fetch-data/tree/master/schemas/ Mais ces descriptions peuvent être mises plus en avant.

Merci beaucoup ! Une question : les noms des champs ne correspondent pas à ceux de la réponse, est-ce parce qu'ils subissent une minification ?

[bzg]

Merci beaucoup ! Une question : les noms des champs ne correspondent pas à ceux de la réponse, est-ce parce qu'ils subissent une minification ?

Oui : https://git.sr.ht/~codegouvfr/codegouvfr-consolidate-data/tree/master/item/src/utils.clj#L43

[hjonin]

Décrire les points d'API et les modèles de données actuels Les schémas de données sont ici : https://git.sr.ht/~codegouvfr/codegouvfr-fetch-data/tree/master/schemas/ Mais ces descriptions peuvent être mises plus en avant.

Merci beaucoup ! Une question : les noms des champs ne correspondent pas à ceux de la réponse, est-ce parce qu'ils subissent une minification ?

Voir aussi https://git.sr.ht/~codegouvfr/codegouvfr-consolidate-data/tree/main/item/src/utils.clj#L43

[hjonin]

A rediscuter avant dév