Etude de modélisation back des API sur data.gouv.fr

[maudetes]

1ères maquettes : https://www.figma.com/file/9Ai2c1JrRyFNKDSJOXN9wM/%F0%9F%92%BB-Api-et-donn%C3%A9es-restreintes?type=design&node-id=117%3A12719&mode=design&t=akooOxHferqa19wS-1

Contexte

• Fusion api.gouv.fr dans data.gouv.fr
• Obligation modélisation des APIs en HVD
• Notion de DataService en DCAT (utilisé dans le monde géo)
• Apification des données tabulaires

Etat des lieux back

Un jeu de données a une liste de ressources, dont certaines peuvent être de type API.

class Resource:
    type = db.StringField(choicies=["main", "documentation", "api", ..]
    url = ...

class Dataset:
    resources = db.ListField(db.Embededededed(Resource))

Exemples d'autres plateformes

Exemple de modélisation de DataService côté GeoNetwork (plateforme GeoOrchestra) :

• DataService
• Jeu de données associé

Côté OpenDataSoft, ils ont une API principale au niveau de la plateforme mais aussi un swagger par jeu de données.

Approche 1

Nouvelle table dédiée "API".
Dans les datasets, avoir une liste d'APIs (à l'image de liste de ressources).

class API:
    title = ..
    documentation = ...
    limit = ...
    endpoint_url = ...
    contact_point = ... ?

class Dataset:
    apis = db.ListField(API)
    resources = db.ListField(db.Embededededed(Resource))

Il faudra envisager une migration des JDDs qui ont été créés pour référencer des APIs - qui devraient donc être convertis en fiches APIs.

Zones de flou

• api-tabular, qui est porté aujourd'hui au niveau de chaque ressource.

Prochaines étapes

• trouver des use cases d'APIs
• clarifier au niveau produit

Approche 2

Extension du type "api" de ressources

• ajout de doc + limitations, etc.
• ajout liens vers d'autres datasets

On trouve que la possibilité de faire une modélisation n <--> n rend cette approche contraignante, et on ne part pas pour cette solution.

[maudetes]

Related to #1305