Que sont les API internes ?

Que sont les API internes ?

Une API interne, aussi appelée API privée, est une interface que seuls les systèmes, équipes et applications de l'entreprise sont censés appeler. Elle n'est pas publiée pour des développeurs externes. Elle permet par exemple au service de facturation de parler au service utilisateurs, ou à une application mobile de parler à son backend, via un contrat documenté plutôt que des bases de données partagées ou du code ponctuel.

Comment fonctionnent les API internes

Une API interne est une API ordinaire : le plus souvent HTTP avec JSON (REST) ou gRPC, avec des endpoints, une authentification et un contrat versionné. Ce qui la rend interne, c'est qui peut l'appeler, pas la technologie. L'accès est limité par l'emplacement réseau (réseau privé ou VPN), par une API gateway et par des identifiants délivrés aux services et aux équipes. Les bonnes configurations combinent les trois. Les API internes sont le liant des microservices : chaque service possède ses données et ne les partage qu'à travers son API.

On distingue en général trois publics : les API internes pour vos propres équipes, les API partenaires pour des partenaires identifiés sous contrat, et les API publiques pour quiconque s'inscrit.

Exemple : le paiement dans une boutique en ligne

Une boutique exploite des services séparés pour les commandes, le stock et le paiement. Au paiement, le service de commandes appelle GET /inventory/items/42 sur le service de stock et POST /payments sur le service de paiement. Aucun n'est exposé sur Internet, et la page de paiement ne parle qu'au service de commandes. Quand une autre équipe crée un service de retours, elle lit les mêmes contrats au lieu de demander un export de base de données.

Erreurs fréquentes

• Confondre interne et sûr. Être dans le réseau n'est pas une autorisation. Si un service est compromis, toute API interne sans contrôle propre est ouverte. L'OWASP API Security Top 10 (2023) cite Broken Object Level Authorization et Improper Inventory Management, deux risques valables aussi à l'intérieur du périmètre. Voir sécurité des API.
• Pas d'inventaire. Anciennes versions, endpoints de test et routes non documentées s'accumulent. C'est l'API sprawl, et la découverte d'API permet de retrouver ce qui existe déjà.
• Pas de contrat ni de versionnage. Un champ renommé par une équipe casse le service d'une autre sans prévenir.
• Pas de limites. Un seul client interne bruyant peut épuiser un service partagé. Fixez des limites de débit et des timeouts aussi entre services.
• Ne tester que la porte d'entrée. Les pages publiques sont testées, pas les appels qui se cachent derrière.

Tester et surveiller les API internes

Les API internes tombent en chaîne : un appel lent au stock ralentit le paiement. Vérifiez pour chaque endpoint le code de statut, le corps de la réponse et le temps de réponse, et testez-le sous charge concurrente. La surveillance d'API de LoadFocus exécute ces vérifications à intervalle régulier (toutes les 5 minutes avec l'offre gratuite) et vous alerte en cas d'échec, et les tests de charge soumettent un endpoint à des utilisateurs simultanés. Un endpoint accessible uniquement dans un réseau privé ne peut pas être vérifié depuis Internet : dirigez les vérifications vers une copie de préproduction ou une route protégée mais accessible. Pour les endpoints authentifiés, voir le guide des tests de performance d'API avec OAuth2.

Questions fréquentes : API internes

Les API internes sont-elles la même chose que les API privées ?

Dans l'usage courant, oui. Les deux termes désignent une API destinée uniquement aux systèmes et équipes de l'organisation.

Les API internes ont-elles besoin d'authentification ?

Oui. Être sur un réseau privé ne suffit pas. Les services doivent prouver leur identité, et chaque appel doit être contrôlé selon ce que l'appelant a le droit de faire.

Quelle différence entre API internes, partenaires et publiques ?

Le public visé. Les internes servent vos équipes, les partenaires des partenaires identifiés sous contrat, et les publiques tout développeur qui s'inscrit.

Une API interne peut-elle devenir publique ?

Oui, mais il faut plus qu'une nouvelle URL : documentation, engagements de versionnage, limites de débit, autorisation plus stricte et support.

Faut-il tester la charge des API internes ?

Oui. Les services partagés reçoivent le trafic de nombreux appelants, et une limite jamais testée se manifeste souvent par un ralentissement dans le produit d'une autre équipe.