#TeamOpenData

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

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 :

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 : 8 - Proposer un accès aux données par API - GREENDATA pour un impact maîtrisé des données


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

  • :green_circle: D’accord,
  • :orange_circle: Mitigé,
  • :red_circle: Pas d’accord.

0 votant

Vous avez des suggestions ?
Commentez ci-dessous !

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.

1 Like

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

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).