Pourquoi classer vos API par catégories ?

L'aide-mémoire des catégories d'API vous aide à choisir le public, le modèle commercial et la sécurité appropriés pour votre API

Marjukka Niinioja

Partenaire fondateur

Lorsque vous commencez à concevoir une nouvelle API, vous devez toujours vous demander d'abord : « Pour qui est-ce que je la conçois ? » Cela conduit à la structure du réseau et aux mesures de sécurité auxquelles l'API doit s'adapter. Enfin, il y a la question de savoir à qui appartiennent les données et les autres ressources traitées par l'API.

Ces décisions sont un peu plus faciles à prendre si vous pouvez catégoriser l'API d'une manière ou d'une autre. Utilisez des modèles courants. De nombreux experts en API du monde entier ont discuté de la manière dont les API devraient être classées. Par exemple, Kin Lane fait la différence entre les API internes et privées. L'auteur du blog RESTCase utilise les catégories interne, partenaire et public. Par expérience, nous devons dire que Kin Lane, soutenu par Steve Wilmot, est en fait plus correct.

Pour aider nos collègues architectes d'API, Jarkko Moilanen et moi-même avons créé l'aide-mémoire de la catégorie API. L'aide-mémoire compare les concepts d'API ouverte, d'API de données ouvertes, d'API interne, privée, partenaire et publique.

Lors de la rédaction d'un livre sur l'économie des API, nous avons commencé à constater que les termes relatifs aux API n'étaient pas clairs. Dans les blogs consacrés à la recherche scientifique et à l'industrie, les termes étaient utilisés sans les spécifier correctement. La situation était encore pire lors de la traduction des termes et des idées dans d'autres langues. Ou lorsqu'il est utilisé par le secteur public, principalement dans le contexte des API et des données ouvertes.

Dans quelle mesure l'API ouverte est-elle ouverte ?

Les problèmes commencent lorsque l'on utilise des termes tels que Open API. Les gens pensent que le terme « ouvert » est synonyme de 100 % non sécurisé et gratuit. Les termes et les initiatives de l'API ouverte et des données ouvertes sont mélangés. Certaines API ouvertes sont publiques et peuvent être utilisées par tous (ou peuvent s'inscrire pour les utiliser). Certains peuvent diffuser des données ouvertes, c'est-à-dire des données sous licence Creative Commons (CC0) ou d'autres licences similaires. De plus, les données ouvertes peuvent être gérées avec d'autres méthodes que les API REST. Mais toutes les API ne sont pas des API ouvertes et la plupart des fournisseurs d'API ouvertes ont besoin que les utilisateurs d'API s'enregistrent.

Le terme a été utilisé pour la première fois en 1996. Il a été utilisé par Sun Microsystems pour décrire les API des extensions Java. Les API étaient « des API publiées, uniformes et ouvertes que tout le monde peut implémenter et utiliser pour créer une extension ». Le terme a ensuite été adapté et associé aux API REST. L'initiative Open API de la Linux Foundation utilise le terme spécification d'API ouverte pour décrire les API REST. De manière confuse, la spécification peut également être utilisée pour concevoir des API internes.

API publiques et partenaires

Nous avons consulté et travaillé dans des entreprises des secteurs public et privé, grandes et petites. Lors de la rédaction du livre API Economy, nous avons comparé nos notes et discuté avec notre communauté Facebook. Nous avons découvert qu'il était crucial de définir votre terminologie dès le début. Par exemple, si l'audience provenait principalement du secteur public, ils ont confondu l'API publique avec les API fournies par le secteur public. Les entreprises avaient peur de lancer des API car elles pensaient que tout devait être public et gratuit.

Nous avons utilisé la définition qui semble la plus courante, à savoir que l'API ouverte est une API publique ou partenaire. Une API destinée à être utilisée conformément aux conditions d'utilisation par des parties externes.

Comme les API ouvertes de la plate-forme Java, ces API REST ouvertes sont conçues pour que d'autres puissent réutiliser et étendre leurs fonctionnalités. Les utilisateurs d'API peuvent créer de nouveaux services à l'aide de ces API ouvertes. La principale différence entre une API publique et une API partenaire est de savoir qui peut l'utiliser. Les API publiques peuvent être utilisées par n'importe qui sans avoir de relation commerciale avec l'organisation qui fournit l'API. Les API partenaires sont disponibles après avoir accepté l'accord du partenaire ou du client ou acheté un service ou un produit.

API internes et privées

Une API interne n'est pas accessible au public et son utilisation est gratuite. Une API interne peut avoir une politique stricte de gestion des identités et des accès, même pour les accès internes. Malheureusement, les API internes sont généralement très mal sécurisées. La seule protection consiste souvent à accéder au réseau interne lui-même ou à l'aide d'une simple clé API partagée par de nombreuses personnes.

Dans les API internes, les données et autres ressources sont souvent différentes des API externes. Une API de produit peut être une API qui fournit des informations de base sur les produits, telles que les codes GTIN/EAN, les noms des produits et les fonctionnalités. Une API interne peut inclure des codes de marge bénéficiaire ou de stockage. Informations non nécessaires pour les clients, les partenaires et en particulier les concurrents.

Au moins la plupart des API internes devraient disposer de modèles de données clairs et d'une sécurité comme s'il s'agissait d'API ouvertes. Elles devraient également être documentées de la manière dont il est possible que les API soient ouvertes un jour, mais cela facilitera encore l'expérience interne des développeurs. La raison de l'utilisation d'API sécurisées adaptées aux API publiques est que les API privées sont utilisées dans l'Internet public, par exemple par des applications mobiles. Kin Lane place ces API dans la catégorie des API privées. Le blog Rest Case place les API d'applications mobiles et les API utilisées au sein du réseau interne dans la même catégorie, interne. De toute façon, avec autant d'implémentations cloud et SaaS, le concept de réseau interne est souvent flou. Ainsi, l'utilisation d'une catégorie peut convenir à de nombreuses entreprises. Nous avons classé les API privées et internes dans la même catégorie.

Il est normal que les grandes entreprises disposent de nombreuses API qui ne peuvent pas être exposées à des réseaux externes. La raison en est généralement la conformité, légale ou conforme à la politique de l'entreprise. Un exemple typique est également celui des API des organisations publiques qui traitent des informations classifiées ou sensibles. Dans un autre cas, les API internes peuvent être fournies par des applications internes. Il peut s'agir de licences commerciales basées sur l'utilisateur, de conceptions de terminaux moins conviviales, de SLA médiocres et d'une évolutivité pour un public plus large. Ces API doivent être traitées comme des API internes, même si les systèmes s'exécutent dans des clouds publics.