Une API dont la documentationne ment pas.
Une référence d’API écrite à la main se périme au troisième changement, et personne ne le voit. Elle se GÉNÈRE depuis le code, et un test refuse de passer si le code et la référence divergent — c’est exactement ce que Nexus fait pour sa propre API.
L’API en production, avec ses clés et ses plafonds
La référence générée depuis le code, et le test qui empêch
La suite d’essais, cas d’erreur compris
La règle de versionnement écrite, et le plan de recouvreme
Comment ça se passe.
Le contrat, et ce qui le fait respecter
Chaque entrée est validée par un schéma, aux frontières : route, événement, message. Une donnée non validée est une panne qui attend son jour.
La référence, générée
Un inventaire des routes produit depuis le code, et un test qui rougit quand la documentation publiée ne correspond plus. Sans lui, elle part en retard d’une version.
Le versionnement
Ajouter un champ est gratuit ; en retirer un ou changer un type est un changement de PROTOCOLE qui demande une version, une période de recouvrement et un avis aux clients.
Les essais, et la charge
Les cas d’erreur autant que les cas qui marchent : un 429 lisible, un 404 qui ne dit pas si la ressource existe ailleurs, un plafond annoncé dans la réponse.
Ce que vous recevez à la fin
L’API en production, avec ses clés et ses plafonds
La référence générée depuis le code, et le test qui empêche la divergence
La suite d’essais, cas d’erreur compris
La règle de versionnement écrite, et le plan de recouvrement
Questions fréquentes
Une API dont la référence est générée depuis le code, testée, versionnée, et dont les changements de contrat ne cassent pas vos clients.
Une autre question ? Écrivez-nous →Faut-il découper en microservices ?
Presque jamais au début. Un découpage prématuré remplace un problème de code par un problème de réseau, qui est plus difficile. On découpe quand une partie a un rythme de déploiement ou une charge vraiment différente.
Comment prévient-on les clients d’un changement ?
Par une version, et par une période où les deux répondent. Une API qui change sans prévenir casse des intégrations qu’elle ne connaît pas : un plafond ou un champ retiré se voit en production, chez quelqu’un d’autre.
Un agent peut-il appeler l’API pendant le développement ?
Oui, c’est même la meilleure façon de l’éprouver : il l’interroge avec une clé de test, lit les réponses réelles et corrige ce qui ne correspond pas à la référence.