Qu'est-ce qu'une API ouverte ou qu'est-ce qui fait qu'une API est largement adoptée ?

Il est très difficile d'établir une définition claire d'une API ouverte. La discussion se transforme rapidement en un débat sur les valeurs et en une définition d'objectifs au lieu d'une définition issue d'un « dictionnaire ». En anglais, le mot API ouverte a une origine et un objectif très différents de ceux, par exemple, des données ouvertes ou des concepts open source.

Vous obtenez ce que vous commandez. Voulez-vous que l'API soit utilisée par le plus grand nombre de consommateurs pour obtenir un résultat impressionnant ? Ensuite, vous devez faire attention à la manière dont l'API est fournie et acquise. Surtout si vous commandez des travaux de développement, des produits ou des technologies qui incluent des API. Les conditions légales jouent un rôle clé dans l'ouverture de l'API.

Les objectifs du secteur public par rapport au secteur privé peuvent parfois sembler contradictoires en ce qui concerne l'ouverture des API. Le secteur public et les organisations non gouvernementales se sont récemment montrés enthousiastes en faveur de services de données ouvertes. Cela est dû aux exigences de transparence, mais aussi à la nécessité d'éviter les blocages entre fournisseurs. L'étape suivante consiste à développer des applications sous forme de code source ouvert, puis à diffuser les données ouvertes via des API. Il semble logique que si les données ouvertes et l'open source peuvent être largement utilisées et principalement gratuitement, en fonction de la licence ouverte choisie, alors pourquoi ne pas utiliser des « API ouvertes ». Mais c'est là l'astuce, même si les données ouvertes, les sources ouvertes et les API ouvertes ont tous les yeux ouverts, leur évolution historique a été différente.

Pourquoi choisir une API ouverte ?

La fourniture d'une API a souvent pour but d'accroître les avantages commerciaux ou sociétaux. Cela nécessite généralement que l'API soit adoptée aussi largement que possible. Bien que toutes les raisons ci-dessous soient pertinentes pour les API externes, souvent appelées API publiques ou partenaires, bon nombre d'entre elles le sont également pour les API internes.

Une API largement adoptée permet de :

• rentabilité,
• la rapidité du développement et du changement,
• la facilité d'utilisation et, en particulier, l'émergence d'un impact sur le réseau, et
• soutenir un écosystème ayant les mêmes objectifs,
• augmentation de la part de marché ou de l'impact

‍

Votre API sera largement adoptée si...

Il existe plusieurs manières de faire en sorte que votre API soit largement adoptée. L'une des solutions consiste à standardiser l'API, ce qui peut être un processus lent. Une autre option consiste à créer une norme dite de facto. Cela implique des moyens de garantir l'adoption de l'API par un groupe important et croissant de consommateurs.

Ce n'est qu'en mettant en œuvre une API facile à utiliser, bien documentée, exempte d'erreurs et suffisamment performante que son utilisation devrait augmenter. De plus, pour que l'API soit largement utilisée, elle a besoin des mêmes éléments que les logiciels open source :

• Une équipe ouverte de développeurs
• Procédure ouverte pour signaler les idées de développement, les erreurs et les demandes d'assistance
• Feuille de route transparente
• La possibilité d'influencer la prise de décisions en matière de développement.

Plus une API est ouverte, mieux elle répond également à ces exigences :

• Niveau adéquat et promesse de service
• Une implémentation technique courante de l'API
• une description de l'API basée sur des normes et d'autres documents accessibles au public, et
• Marketing et communication complets, afin que les informations sur l'API atteignent les consommateurs potentiels
• Dans l'idéal, la documentation de l'API devrait être publiée de telle sorte que sa visualisation ou l'évaluation de son utilisabilité ne nécessitent pas encore la conclusion d'un contrat ou l'acceptation de conditions contractuelles, ni la demande de droits d'accès.

Si tous les tiers intéressés ont accès à l'API, le terme API publique est souvent utilisé. Si seules certaines parties extérieures à l'organisation sont autorisées à utiliser l'API, le terme API partenaire est utilisé. En outre, différentes parties de l'organisation peuvent fournir des API pour elles-mêmes et pour les autres, auquel cas elles sont appelées API internes. Dans de nombreuses sources, les API ouvertes sont définies comme des API publiques. Certaines sources incluent également des API partenaires. (Moilanen, Niinioja, Seppänen, Honkanen, API economy 101, 2019)

‍

Accroître l'ouverture grâce à des licences et à des normes ouvertes

L'ouverture de l'API peut être améliorée en octroyant des licences ouvertes aux modèles de données, à la documentation et aux instructions. L'API doit également utiliser des modèles de données standard dans la mesure du possible.

L'utilisation de licences et de normes ouvertes est particulièrement importante si l'utilisation plus large de l'API oblige également les parties à copier l'API sur leurs propres systèmes et technologies d'information. Cela est généralement lié aux logiciels open source qui incluent une API. Il ne suffit pas de copier la définition de l'interface API ou le modèle de données pour garantir que la copie de l'API fonctionne de la même manière ou que les versions futures seront compatibles. La mise en œuvre technique conjointe ou intégrée, ainsi qu'une équipe ouverte de développeurs, peuvent être plus importantes que les licences ouvertes en elles-mêmes.

Les licences ouvertes peuvent contribuer à la formation et à l'intérêt d'une équipe de développeurs. Si l'ensemble du code source du système est concédé sous licence ouverte, les ressources associées à l'API peuvent être incluses dans cette licence. Si le logiciel ou toute autre technologie implémentant l'API a été copié, les conditions d'utilisation des données peuvent être complètement séparées des conditions d'utilisation de l'API. Cela signifie que l'API est gérée par chaque client sur son propre réseau, sur ses propres appareils ou dans le cloud sous son propre contrôle. De plus, l'API interagit avec ses propres ressources (données, bâtiments, algorithmes, etc.).

‍

Les données fournies ou reçues par l'API ouverte sont-elles toujours sous licence ouverte ou gratuites ?

Pas toujours, mais il peut y avoir plus d'opportunités que vous ne le pensez. Par exemple, les informations fiscales communiquées par les entreprises à l'administration fiscale par le biais d'API ne sont pas, en tant que telles, des données publiques. L'API peut être librement accessible à toutes les entreprises fournissant des services à d'autres entreprises ou pour leur propre usage. Cependant, certaines données peuvent être publiées, par exemple, en tant que données ouvertes en vertu de la loi sur la publicité ou d'autres lois relatives aux informations fiscales.

Si les consommateurs de l'API sont en fait des utilisateurs de SaaS et payent pour l'abonnement au logiciel, les données qu'ils utilisent via l'API sont « leurs données » et sont « gratuites » dans le sens où ils ne paient pas spécifiquement pour l'API ou n'utilisent pas les données via l'API. Mais ils le pourraient, selon les termes et conditions. Et ils peuvent avoir des restrictions quant à la quantité de données et à la fréquence à laquelle ils sont autorisés à demander sans payer de supplément.

‍

L'API ouverte est-elle toujours gratuite ?

Les données ouvertes et le code source ouvert sont souvent considérés comme gratuits. Certaines définitions permettent également de collecter des frais raisonnables pour ouvrir les données ou le code source. Cependant, il est essentiel de séparer les données et le code source de l'API elle-même.

Une API gratuite ou abordable est certainement plus populaire et plus largement utilisée qu'une API payante. Il existe toujours des options freemium, pour lesquelles vous disposez d'une durée ou d'une limite de demandes gratuites.

La principale conclusion à tirer des différences entre les données ouvertes, le code source ouvert et l'API ouverte est qu'une API ouverte ou « fermée », c'est-à-dire publique, partenaire ou interne, peut être construite sur du code source ouvert (ou non). Il peut proposer les données sous licence ouverte ou non. La description de l'interface de l'API et la documentation peuvent être concédées sous licence ouverte ou non. En fonction des normes de l'industrie, de la législation, des cas d'utilisation et des attentes de la communauté, le meilleur choix est d'être aussi ouvert que possible, tout en gardant à l'esprit les réalités. Quelqu'un doit être en mesure de payer la facture au final.

‍