8 - Proposer un accès aux données par API

mbrient · Juillet 12, 2022, 2:18

CONTEXTE

L’interopérabilité pour faciliter l’accès et la réutilisation de données

Le Web est une machine à développer des services. Basés sur une architecture dite « REST », de nombreux services peuvent, selon leur configuration, consulter et mettre à jour facilement des données ouvertes.

Afin de faciliter l’accès et la réutilisation de données, la mise en place d’interfaces de programmation applicative (API) visent à mettre à disposition des données dans un format facilement utilisable. Plutôt que de dupliquer et héberger soi-mêmes des jeux de données, les API facilitent les récupération et actualisation. Ainsi, chaque donnée mise à jour est automatiquement actualisée dans l’ensemble des services les mobilisant par API .

Bénéfices d’accès aux données par API :

Ne transférer que les données nécessaires au bon moment
Ne pas multiplier les duplications et donc réduire les besoins de stockage
Faciliter la récupération et donc la valorisation et l’usages des données ouvertes

DESCRIPTION DE LA BONNE PRATIQUE

Architecture : Certains éditeurs de portails OpenData proposent de manière systématique le déploiement d’API. Cette fonctionnalité facilite de fait l’interopérabilité et la récupération de jeux de données.

Interopérabilité : Pour garantir ce critère d’interopérabilité des données et des services mais aussi harmoniser et faciliter la récupération de données, il est recommandé d’utiliser le principe d’architecture REST et le principe d’encodage JSON . D’autres formats pourraient être à encourager notamment pour les données dites chaudes, temps réels, comme le format BSON ou encore CBOR.

Critères d’achat : Dans certains cas, il peut être pertinent d’intégrer des critères de mises à disposition d’API et modalités d’accès, dans les cahiers des charges qui encadrent les prestataires (assurer le développement d’API, garantir une infrastructure propice à la mise à disposition d’API, …)

Documentation : Pour chaque API proposée, il convient d’expliciter : - une documentation technique présentant les modalités d’interrogation, rythme d’actualisation, formats ou encore modalités de récupération de la donnée. - les conditions générales d’utilisation qui précise si besoin, le processus de demande d’accès, la durée ou encore si nécessaire les critères d’éligibilité des réutilisations.

API existantes : Le service api.gouv.fr propose de nombreuses données ouvertes et la documentation nécessaire pour aller les récupérer et les intégrer aux services et portails OpenData. Voici quelques exemples de bases de données accessibles par API spécifiques :

Géorisques naturels et technologiques des territoires
Piézométrie (niveau des nappes d’eau souterraine)
l’ensemble des adresses du territoire français
les Diagnostic de Performance Energetique des logements particuliers (DPE)

L’accès par API ne peut être exclusif : La CADA a récemment statué que « la consultation sur Internet de documents librement communicables ne saurait être subordonnée à une procédure de demande d’accès impliquant une autorisation préalable de l’administration ». Autrement dit, bien qu’un accès par API peut-être pratique et facilitant, il ne doit être exclusif et opérer un accès restreint à des données publiques.

RETOUR D’EXPERIENCE

Contrôler les flux d’API - ADEME
Pour protéger l’infrastructure de publication de données de l’Ademe, les appels sont limités par quelques règles simples : Un utilisateur anonyme ne peut pas effectuer plus de 100 requêtes par intervalle de 5 secondes. Sa vitesse de téléchargement totale est limitée à 2 MB/s pour les contenus statiques (fichiers de données, pièces jointes, etc.) et à 500 kB/s pour les autres appels.

Référencer son API
Si vous souhaitez mettre à disposition et référencer votre API, vous pouvez l’enregistrer sur ce portail : Référencer une nouvelle API - api.gouv.fr

EVALUATION

Priorité :

prioritaire,
recommandée,
pour aller plus loin

Mise en œuvre :

facile,
moyenne ,
difficile

Exemple de pilote : Délégué ou référent aux données ouvertes et responsables

Exemple(s) d’indicateur(s) de pilotage

% de données ouvertes disponibles par API

Lien vers la fiche : BP 7 - Proposer un accès aux données par API - GreenData- pour un impact environnemental maîtrisé

Votre avis nous intéresse.
Que pensez-vous de ces propositions ?

D’accord,
Mitigé,
Pas d’accord.

0 votant

Vous avez des suggestions ?
Commentez ci-dessous !

nicolas-bonnel · Juillet 21, 2022, 10:30

Sur la partie documentation, il peut être intéressant de mentionner des standards comme OpenAPI :

Cela permet aux reutilisateurs de s’y retrouver plus facilement dans la documentation, il peuvent même utiliser le visualisateur de documentation de leur choix compatible avec la norme.
Cela augmente encore plus l’interopérabilité car la documentation devient compréhensible par d’autres système informatiques. Une API documentée via OpenAPI peut par exemple être intégrée très rapidement sur api.gouv.fr

Une autre notion importante liée en partie aux architectures REST est la mise en cache : pour réduire au maximum les transferts et donc la dépense d’énergie, il est crucial de bien maitriser la manière dont sont mises en cache les ressources. Cela ne sert pas trop pour le téléchargement de gros fichiers, mais convient bien par exemple à la consultation de données cartographiques avec les fonds de carte qui peuvent être mis en cache.

Flacombe · Juillet 24, 2022, 8:50

Le format dépend largement des données à représenter.
Pourquoi spécifier le json ou quoi que ce soit d’autre ici ?

bninassi · Août 4, 2022, 1:46

Même remarque que pour le 7-3 : Il est également important de préciser que ces API doivent permettre d’effectuer des requêtes pour filtrer/trier les données à la source (ça semble implicite, mais il vaut mieux le rendre explicite) : il est toujours possible de produire une API ne permettant que de récupérer l’intégralité des données (ce qui n’est pas le but recherché ici).

cquest · Août 12, 2022, 8:13

Les API ont aussi des inconvénients et pas que des bénéfices !

Je vais faire court… et long à la fois:

thomyphi · Août 28, 2022, 5:20

Bonjour,

Le thème de l’API recouvre deux sujets :

la demande : comment est-ce qu’on formule l’interrogation avec deux sous-questions :
- comment est-ce qu’on connait la structure des données à interroger (niveau sémantique) ?
- comment est-ce qu’on formule une requête ?
la réponse : comment est-ce qu’on récupère les données avec la aussi deux sous-questions :
- comment sont structurées les données renvoyées au niveau sémantique (différent de la structure des données interrogées et différent aussi en fonction de la nature de la requête) ?
- comment sont formatées les données ?

Les questions sur la sémantique sont les mêmes que pour les échanges par fichier (csv ou autre) et la réponse est d’une part de fournir une représentation de la structure de données (ex. un modèle de données de type UML) et d’autre part de fournir des objets élémentaires avec un sens métier (ex une date, une position plutôt qu’un string ou un dict).

Pour les requêtes, il semble important de creuser le sujet (mais je ne maîtrise pas suffisamment le sujet pour aller plus loin).

Pour les formats d’échange, le JSON est effectivement le format privilégié (mais il faudrait peut-être en citer d’autres). A noter que les formats BSON, CBOR et JSON-text sont tous des représentations du format JSON-objet. (BSON est le format JSON de MongoDB et CBOR est un format binaire du JSON).