API et intégrations

Ce que couvre cette catégorie

Quatre métiers voisins se retrouvent ici. Construire et tester des requêtes à la main. Documenter une interface pour que d’autres puissent l’utiliser. Placer une passerelle devant plusieurs services pour que clés, limites de débit, quotas et versions se comportent partout de la même manière. Déplacer des données entre des produits qui n’ont jamais été conçus pour se parler.

Les trois premiers s’adressent aux équipes qui livrent une API. Le quatrième, à quiconque assemble des outils achetés. Les deux publics se retrouvent sur ce rayon, ce qui explique que les produits se ressemblent si peu.

L’automatisation purement visuelle, sans code, relève de no-code et automatisation. L’alerte sur un service en production, c’est de la supervision.

Les clients, et ce qui les distingue aujourd’hui

Tout client envoie une requête et affiche une réponse. Les différences se situent plus loin.

La gestion des environnements d’abord : local, préproduction, production et ce que fait tourner un collègue sur son portable, avec une bascule propre sans que personne modifie une URL à la main. Puis le scripting, pour qu’un jeton soit récupéré avant une requête au lieu d’être collé chaque matin. Puis les assertions de test, pour qu’une collection devienne quelque chose qu’un serveur de build peut exécuter.

La collaboration est là où les avis se partagent. La synchronisation dans le cloud est pratique et place l’historique de vos requêtes sur les serveurs de quelqu’un d’autre. Les outils fondés sur des fichiers gardent les collections dans le dépôt, à côté du code : un changement se relit comme n’importe quel autre, et aucun espace de travail ne part avec un employé qui s’en va.

Dans les deux cas, demandez où vivent les secrets. Une clé écrite dans une collection exportée est la voie classique vers un dépôt public.

Une documentation qui ne moisit pas

Une documentation écrite à la main est périmée en un trimestre. Le seul arrangement qui tient est la génération à partir d’une spécification qui vit avec le code et se reconstruit quand le code est fusionné.

Vérifiez trois choses : si le produit lit le format de votre spécification sans étape de conversion, si les exemples peuvent être exécutés depuis la page, et si les anciennes versions restent publiées pour ceux qui les utilisent encore.

Un journal des modifications compte plus que le design. Les consommateurs doivent savoir ce qui a cassé et quand, et aucune mise en forme ne remplace cela.

Les passerelles, et quand elles valent le coup

Un service unique a rarement besoin d’une passerelle. Le cas se présente quand authentification, limites de débit, quotas et versionnement doivent se comporter à l’identique sur plusieurs services.

Les questions sont alors : où elle tourne et quelle latence elle ajoute, comment les limites sont définies et ce que voit l’appelant quand l’une est atteinte, si les clés peuvent être renouvelées sans interruption, et ce que contiennent les journaux. Tout ce qui termine le trafic devient un risque de disponibilité à part entière : demandez ce qui se passe quand la passerelle elle-même a un mauvais jour.

Ce que mesure la tarification

• Postes sur les clients et les produits de documentation, parfois gratuits pour les relecteurs en lecture seule.
• Tâches ou exécutions sur les plateformes d’intégration, comptées par étape plutôt que par flux.
• Appels ou bande passante sur les passerelles, avec un tarif distinct pour ce qui est mis en cache.
• Rétention de l’historique d’exécution, courte sur les formules d’entrée et courte précisément quand vous en avez besoin.
• Connecteurs, les premium étant rangés un niveau au-dessus de la formule chiffrée.

La tarification à la tâche mérite un calcul avant la signature. Un flux de six étapes qui s’exécute toutes les dix minutes n’est pas une tâche par mois, et le nombre qu’il devient a surpris beaucoup d’équipes. La même forme de surprise dans d’autres catégories est rassemblée dans ce que cachent les pages de tarifs.

Que tester

Reconstruisez de bout en bout une intégration réelle que vous exploitez déjà, y compris le moment où l’autre côté renvoie une erreur.

Observez comment l’outil traite les nouvelles tentatives, la livraison en double, un tiers qui se fige et une charge utile arrivée avec un champ manquant. Les produits bien conçus permettent de rejouer une exécution échouée après avoir corrigé la cause. Les plus faibles la perdent en silence et ne vous disent rien tant qu’un client ne l’a pas fait.

Vérifiez ensuite la sortie. Collections, spécifications et définitions de flux doivent pouvoir s’exporter en fichiers lisibles. Tout ce qui reste enfermé dans un espace de travail est du travail que vous ferez deux fois.

Documentation, versionnement et fidélisation des consommateurs

Une interface qui a des utilisateurs est une promesse, et l’essentiel de la difficulté de cette catégorie vient du fait de la changer sans trahir cette promesse.

Décidez d’une approche de versionnement avant l’arrivée du premier consommateur externe, car en installer une après coup revient à demander à tout le monde de changer en même temps. Quel que soit le schéma, publiez ce qui a changé et quand, et prévoyez une période d’obsolescence mesurée en mois plutôt qu’en semaines.

Les erreurs méritent autant d’attention que les succès. Une réponse qui dit ce qui a échoué, quel champ en est la cause et quoi faire ensuite supprime plus de demandes au support que n’importe quelle quantité de prose.

Relisez ensuite votre propre documentation comme le ferait un nouvel arrivant. L’amélioration la plus rapide est généralement un exemple qui fonctionne en haut de la page plutôt qu’un tableau de référence.