3 commandements qui devraient guider chaque stratégie API

« Les API doivent être appelables de manière indépendante, apatrides et idempotentes », déclare Kelly Goetsch, directrice de la stratégie chez commercetools et auteur de quatre livres sur les API et les microservices. Cela signifie qu’une application peut utiliser une API sans avoir à en appeler une autre au préalable, et que les valeurs internes du service ne sont pas modifiées de manière à produire un résultat différent à chaque appel. Par exemple, vous pouvez appeler une API pour l’ajouter à un panier plusieurs fois — et si elle est idempotente, elle agira de la même manière à chaque fois qu’elle sera invoquée.

Enfin, la politique doit garantir qu’il n’y a aucune distinction entre les API uniquement internes et les API externes. « L’un des aspects brillants du mandat Bezos était de dire que les API devaient être externalisées par défaut », explique Rasmussen. « Et si vous regardez AWS, qui a commencé comme un projet interne, ils l’ont rendu accessible au monde extérieur en modifiant simplement l’accès à ce qui était déjà utilisé au sein de l’entreprise. »

Une fois qu’une politique API est mise en place, l’essentiel est de s’assurer que toutes les équipes y adhèrent. Avec autant de pièces mobiles, de connexions et de données en transit, il s’agit d’un aspect crucial qu’aucun responsable informatique ne devrait négliger.

3. Créer et maintenir un catalogue d’API

Avec une telle gamme de services susceptibles d’être nécessaires pour réaliser votre vision API, il est également essentiel d’indexer les API que votre organisation crée, ainsi que celles que votre organisation est susceptible de confier à des tiers.

« Les DSI devraient développer un catalogue d’API et une stratégie de gestion de ce catalogue », explique Goetsch. « Le catalogue doit définir les API et inclure toutes les fonctionnalités dont l’entreprise a besoin. Ensuite, vous pouvez décider de créer ou d’acheter le logiciel qui fournit ces services.

Même si le catalogue doit être géré de manière centralisée, la responsabilité de sa mise en œuvre doit être laissée à des équipes individuelles ou à des fournisseurs externes. Mais ceux qui développent les services doivent être liés par ce qui est défini dans le catalogue, explique Goetsch.

« Les équipes qui mettent en œuvre les API peuvent choisir leur base de données et bien d’autres choses », explique-t-il. « Mais s’ils font des erreurs, tenez-les pour responsables. Vous pouvez déterminer très rapidement et facilement si une équipe la gère correctement. Si les API tombent en panne, vous savez que vous avez un problème.

Le catalogue central doit être bien documenté et accompagné d’outils de découverte permettant aux utilisateurs internes et externes de trouver des API en fonction d’une description de leurs besoins ou d’un ensemble de mots-clés. « Le groupe Lego a investi dans des outils de découverte centralisés pour aider les développeurs à trouver les API des autres et à les utiliser pour composer un produit plus volumineux, tout comme les gens le font avec les briques Lego », explique Edwards.

En adhérant à ces trois commandements et en tenant compte de la sagesse acquise au fil des années d’expérience, les responsables informatiques peuvent créer un cadre qui garantit un chemin clair vers chaque service. Les consommateurs peuvent compter sur une interface solide et les producteurs bénéficient de la liberté dont ils ont besoin pour créer des services. Chaque partie peut innover à son rythme.