Qu’est-ce qu’un point de terminaison d’API ?

Les API et les points de terminaison (Endpoint) ont toujours été un sujet de discussion brûlant parmi les développeurs frontend et backend. Pour développer des applications et des services utiles et durables, les API ont été des moyens puissants et facilitateurs.

Les API facilitent la transmission de données entre divers artefacts logiciels pour résoudre les problèmes des clients. Presque tous les produits modernes basés sur le web offrent leurs propres API pour interagir et intégrer leurs services directement dans tout projet.

Pour ne pas vous laisser distancer par vos concurrents et offrir à vos utilisateurs une expérience transparente sur toutes les plateformes, vous devez connaître et maîtriser le jeu des API.

Ce guide va décomposer le terme et vous aider à apprendre ce qu’est un point de terminaison d’API, comment vous pouvez consommer une API publiquement disponible, et les différentes façons de sécuriser et de surveiller vos point de terminaison d’API.

Comprendre les points de terminaison d’API

« API » est l’abréviation de « Application Programming Interface » Il s’agit essentiellement d’un ensemble de règles qui permettent à une application de partager ses données avec d’autres applications. En termes simples, une API vous permettra de « partager des choses » entre votre application et une application tierce.

Un point de terminaison d’API est un emplacement numérique exposé via l’API à partir duquel l’API reçoit des requêtes et envoie des réponses. Chaque point de terminaison est une URL (Uniform Resource Locator) qui fournit l’emplacement d’une ressource sur le serveur API.

Pour comprendre le but et l’utilisation des API, comprenons d’abord comment elles fonctionnent.

Comment fonctionnent les API

Pour que deux applications logicielles communiquent sur Internet, une application (appelée client) envoie une requête aux points de terminaison de l’API de l’autre application (appelée serveur). Selon les capacités de l’API, le client peut demander une ressource à une base de données ou demander au serveur d’effectuer une action dans son environnement et de renvoyer les résultats.

À la réception du résultat du client, l’API (ou le serveur) effectue l’opération demandée et renvoie le résultat de l’opération au client sous la forme d’une réponse. Cette réponse peut également inclure toutes les ressources que le client a demandées.

Il peut y avoir différents types d’API, notamment REST, SOAP et GraphQL. Elles fonctionnent toutes différemment, mais leur objectif est toujours le même : faciliter la communication entre les entités basées sur le web. Dans ce guide, nous parlerons principalement des API REST car elles font partie des API les plus populaires au monde.

Quelle est la différence entre une API et un point de terminaison ?

Cela nous amène à la question suivante, la plus courante : Quelle est la différence entre une API et un point de terminaison ?

Une API est un ensemble de protocoles et d’outils destinés à faciliter l’interaction entre deux applications. Un point de terminaison est un endroit de l’API où l’échange a lieu. Les points de terminaison sont des URI (Uniform Resource Identifiers) sur une API auxquels une application peut accéder.

Toutes les API ont des points de terminaison. Sans point de terminaison, il serait impossible d’interagir avec une API.

Comment les points de terminaison fonctionnent-ils avec les API ?

Pour approfondir votre compréhension des API et des points de terminaison, reprenons un petit exemple.

Prenons l’API Cat Facts. Cette API fournit des informations aléatoires sur les chats. Cependant, elle répertorie divers points de terminaison à l’aide desquels vous pouvez demander des informations catégorisées. Il existe trois points de terminaison disponibles :

• /fact: Renvoie un fait unique et aléatoire sur les chats.
• /facts: Renvoie une liste de données aléatoires sur les chats.
• /breeds: Renvoie une liste de races de chats.

Pour faire une requête sur cette API et récupérer une information sur les chats, vous devez ajouter le point de terminaison correct (qui est /fact) à l’URL de base de l’API (qui est https://catfact.ninja/). Cela vous donnera l’URL de point de terminaison suivante : https://catfact.ninja/fact

Si vous envoyez une requête GET à l’URL ci-dessus, vous obtiendrez un résultat similaire :

{
    "fact": "Spanish-Jewish folklore recounts that Adam\u2019s first wife, Lilith, became a black vampire cat, sucking the blood from sleeping babies. This may be the root of the superstition that a cat will smother a sleeping baby or suck out the child\u2019s breath.",
    "length": 245
}

Maintenant, vous n’auriez pas été en mesure d’obtenir ces données si vous aviez accédé à un autre point de terminaison, tel que /breeds. C’est ainsi que les points de terminaison aident à interagir avec et à organiser les ressources fournies par une API – chaque point de terminaison est spécifique à une partie particulière des données.

Pourquoi les points de terminaison d’API sont-ils importants ?

Le transfert de données et le partage de ressources font partie des bases fondamentales de l’Internet. Chaque jour, de plus en plus de processus et d’applications sont ajoutés au réseau mondial, ce qui ajoute de la valeur au réseau en partageant des choses.

Sans les API, rien de tout cela ne serait possible. Les API constituent un puissant moyen de communication et d’interaction entre les applications basées sur le web.

Les points de terminaison d’API quant à eux, aident à déterminer l’emplacement exact des ressources dans l’API. Ils aident les développeurs d’API à organiser les ressources disponibles et à contrôler également l’accès des consommateurs. Par conséquent, les performances et la productivité des applications consommant des API dépendent directement de la conception et des performances des points de terminaison d’API.

Travailler avec des points de terminaison d’API existants

Dans la plupart des cas, vous serez amené à consommer des API pré-construites. Pour le faire efficacement, vous devez comprendre comment localiser les points de terminaison et vous y retrouver dans les diverses règles de versionnage utilisées dans le secteur. Cette section vous guidera à travers celles-ci.

Localiser un point de terminaison d’API

La localisation d’un point de terminaison d’API est une tâche simple si vous avez accès à la documentation de l’API. Parfois, la documentation peut énumérer les points de terminaison simplement avec de courtes descriptions à côté de chacun d’eux. Dans d’autres cas (comme Swagger), la documentation peut être plus complexe et plus puissante, et vous pouvez être en mesure de tester les points de terminaison directement à partir de la page de documentation.

Dans tous les cas, il est dans votre intérêt de consacrer du temps à comprendre l’objectif de chaque point de terminaison avant de commencer à l’utiliser. Cela peut vous aider à éviter la plupart des erreurs et à améliorer votre efficacité.

Versionnage des points de terminaison d’API

Comme la plupart des autres artefacts logiciels, les API sont également versionnées. Le versionnage permet d’observer et d’analyser l’API au fur et à mesure de son évolution au cours du processus de développement. Avoir accès aux anciennes versions peut également vous aider à revenir à des versions antérieures et stables en cas de mise à jour défectueuse. Voici quelques façons courantes dont les points de terminaison d’API sont versionnés.

Chemin d’URI

L’une des façons les plus populaires de versionner les points de terminaison d’API consiste à inclure un numéro de version dans le chemin d’URI. Voici à quoi cela peut ressembler :

http://example.com/api/1/resourcename

Vous pouvez considérer cette approche comme un moyen de versionner globalement les points de terminaison d’API. Si vous utilisez un sous-domaine pour votre API, tel que :

http://api.example.com/resourcename

… vous pouvez également mettre un indicateur de version dans votre sous-domaine, comme ceci :

http://api-v2.example.com/resourcename

Comme vous pouvez le constater, cette approche modifie la route URI de l’API, de sorte que chaque version se comporte comme une ressource indépendante en soi. Cela signifie que vous pouvez accéder simultanément aux deux versions de l’API selon vos besoins et même les mettre en cache indépendamment pour un accès plus rapide.

Lorsque vous incluez un numéro de version dans le chemin URI (et non dans le sous-domaine), voici un format soigné que vous pouvez suivre pour inclure plus d’informations :

MAJOR.MINOR.PATCH

Par exemple, voici comment l’API interne de notre exemple ci-dessus serait versionnée :

http://example.com/api/1.2.3/resourcename

Maintenant, décomposons ces nouveaux termes de version et ce à quoi ils servent :

• MAJOR : Pour les modifications d’API incompatibles
• MINOR : Pour ajouter des fonctionnalités rétrocompatibles
• PATCH : Pour les corrections de bogues rétrocompatibles

La version MAJOR est ici la version utilisée dans l’API publique. Ce numéro est généralement mis à jour lorsqu’un changement majeur ou de rupture est apporté à l’API. En interne, un tel changement indique qu’une nouvelle instance ou ressource API a été créée.

Les versions MINOR et PATCH sont utilisées en interne pour les mises à jour de rétrocompatibilité. Elles sont généralement mises à jour lorsqu’une nouvelle fonctionnalité est introduite ou lorsque des modifications mineures sont apportées à la même ressource API. Le numéro PATCH est mis à jour spécifiquement pour les corrections de bogues ou les mises à jour de résolution de problèmes.

• Avantages :
  • L’accès simultané à plusieurs versions est possible.
  • La dénomination des URL suit une convention simple et standard, de sorte que les points de terminaison de l’API sont très accessibles.
• Limitations :
  • Dans le cas de changements de rupture, cette approche conduit au développement d’une toute nouvelle ressource API. Cela peut ajouter un poids important à votre base de code.

Paramètres de requête

Une autre alternative pour versionner une API REST est de mettre le numéro de version dans les paramètres de requête de son URL. Cela permet à l’environnement du serveur d’accéder au numéro de version requis comme tout autre paramètre de requête et de l’utiliser pour rediriger le flux de contrôle dans l’application. Il n’est pas nécessaire de créer une nouvelle ressource API, car votre ressource API existante peut lire le numéro de version et agir en fonction des besoins.

Voici à quoi ressemblerait l’URL de l’exemple précédent lorsqu’elle est versionnée à l’aide de paramètres de requête :

http://example.com/api/resourcename?version=1

• Avantages :
  • Très facile à mettre en œuvre dans le code.
  • Vous pouvez rapidement passer par défaut à la dernière version.
• Limitations :
  • Les paramètres peuvent être plus difficiles à utiliser pour acheminer les demandes vers la bonne version que le versionnage par chemin d’accès URI.

En-têtes personnalisés

Vous pouvez également versionner les API REST en fournissant des en-têtes personnalisés avec le numéro de version comme attribut. La différence la plus significative entre cette méthode et les deux mentionnées précédemment est que celle-ci n’encombre pas l’URL du point de terminaison avec des informations de version.

Voici à quoi ressemblerait l’exemple précédent s’il était versionné selon cette approche :

curl -H "Accepts-version: 2.0"

http://example.com/api/resourcename

• Avantages :
  • L’URL n’est pas encombrée d’informations sur la version.
  • Les clients peuvent coder en dur les URL des points de terminaison de l’API et choisir entre les versions via les en-têtes tout en envoyant rapidement la requête.
• Limitations :
  • Vous devez définir manuellement des en-têtes personnalisés lors de toute requête.

Négociation de contenu

La négociation de contenu permet aux développeurs d’API de versionner une seule représentation de la ressource au lieu de l’API entière. Cela leur donne un contrôle plus granulaire sur le versionnage. Tout comme la précédente, cette méthode permet également de désencombrer les URL d’API.

Voici à quoi ressemblerait notre exemple précédent s’il était versionné via la négociation de contenu :

curl -H "Accept: application/vnd.kb.api+json; version=2"

http://example.com/api/resourcename

Cependant, les points de terminaison versionnés à l’aide de cette approche sont plus difficiles d’accès que ceux avec l’approche URI. De plus, l’utilisation d’en-têtes HTTP avec des types de médias rend difficile le test de l’API dans un navigateur. Et si l’en-tête de contenu est facultatif, cela peut entraîner une confusion sur la version que les clients recevront par défaut.

Supposons que vous ayez publié une version v2 de votre API et que vous ayez supprimé l’ancienne version v1. Si un client ne spécifie pas la version dans sa requête, il recevra la ressource v2, ce qui pourrait briser sa fonctionnalité en raison de problèmes de compatibilité non pris en compte. C’est pourquoi la négociation de contenu n’est généralement pas recommandée comme moyen de gestion des versions d’API

• Avantages :
  • Vous pouvez versionner une seule ressource si nécessaire.
  • Elle crée une empreinte de code plus petite.
  • Elle ne vous oblige pas à modifier les règles de routage (URL).
• Limitations :
  • Les en-têtes HTTP avec les types de médias rendent difficile le test et l’exploration des points de terminaison dans un navigateur.
  • N’oubliez pas non plus que l’absence d’en-tête de contenu peut briser la fonctionnalité du client.

Exemple d’un point de terminaison d’API

Pour mieux comprendre les API et les points de terminaison, nous allons illustrer un exemple en utilisant l’API Twitter. Cette API expose des données sur les tweets, les messages directs, les utilisateurs et plus encore de la plateforme de réseaux sociaux. Elle propose différents points de terminaison pour effectuer diverses opérations sur ses données.

Par exemple, vous pouvez utiliser le point de terminaison de recherche de tweet (https://api.twitter.com/2/tweets/{id}) pour récupérer le contenu d’un tweet spécifique en utilisant son identifiant unique. Vous pouvez également utiliser l’API Twitter pour diffuser des tweets publics en temps réel dans votre application web afin de tenir vos utilisateurs informés sur un sujet d’intérêt particulier.

L’API Twitter propose un point de terminaison de flux filtré à cet effet (https://api.twitter.com/2/tweets/search/stream). Elle a également créé un index étendu d’autres points de terminaison que vous pouvez utiliser.

Comment les points de terminaison d’API sont-ils sécurisés ?

Maintenant que vous comprenez l’aspect et le fonctionnement d’un point de terminaison d’API, il est essentiel de savoir comment le sécuriser. Sans mesures de sécurité adéquates, un point de terminaison d’API peut constituer une faille majeure dans la protection de votre application, pouvant entraîner des violations de données et de ressources.

Voici quelques suggestions de base pour sécuriser l’accès à vos points de terminaison d’API.

Hachage de mot de passe à sens unique

Lors de la création de ressources web, vous rencontrerez souvent des mots de passe comme moyen d’authentification des entités. Si les mots de passe aident à sécuriser les données d’application de vos utilisateurs, vous devez également sécuriser le stockage des mots de passe pour en faire un moyen d’authentification réellement efficace.

En général, vous ne devriez jamais stocker les mots de passe en texte clair. En cas de violation de la sécurité, tous les comptes utilisateurs seront compromis si un mauvais acteur met la main sur le tableau des paires de chaînes de noms d’utilisateur et de mots de passe.

Une façon d’empêcher cela est de les crypter avant de les stocker. Il existe deux méthodes de cryptage – symétrique et asymétrique.

Dans le cas du cryptage symétrique, vous pouvez utiliser la même clé de cryptage pour verrouiller et déverrouiller le contenu. Cependant, cette méthode n’est pas recommandée pour les mots de passe, car des pirates persistants et sophistiqués peuvent facilement les casser.

La façon recommandée de stocker les mots de passe est d’utiliser un cryptage à sens unique ou « asymétrique ». Au lieu d’utiliser une clé de cryptage unique, une fonction mathématique est utilisée pour brouiller les données.

La version brouillée est stockée dans la base de données afin que personne, y compris les administrateurs du serveur, ne puisse déchiffrer les mots de passe et les consulter. Pour authentifier les utilisateurs, le mot de passe saisi est soumis à la même fonction mathématique, et les résultats sont comparés pour vérifier si le mot de passe saisi était correct.

HTTPS

Supposons que vos points de terminaison d’API soient conçus pour permettre aux consommateurs de parler à vos services. Dans ce cas, vous leur faites courir un risque important en ne mettant pas en œuvre HTTPS (ou un autre protocole de sécurité similaire).

Les connexions API échangent généralement des données sensibles telles que des mots de passe, des clés secrètes et des informations de paiement. Ces données peuvent être facilement volées par une attaque de type « machine-in-the-middle » ou par des méthodes de reniflage de paquets.

C’est pourquoi vous devriez vous faire un devoir de toujours choisir le protocole HTTPS lorsqu’il est disponible. Si vos applications utilisent actuellement le protocole HTTP, vous devriez fortement envisager de migrer vers HTTPS. Peu importe que la connexion soit insignifiante, elle peut toujours conduire à une fuite.

Vous devriez également envisager d’opter pour un certificat TLS ou SSL afin de renforcer la sécurité de votre API.

Limitation du débit

Dans la plupart des cas, fixer une limite au nombre de fois que votre API peut être utilisée en une minute est une bonne idée. Cela vous aide à contrôler toute utilisation abusive des ressources et à mettre en place un modèle de tarification géré basé sur le trafic de vos consommateurs.

Toutefois, l’une des principales raisons de mettre en place une limitation du débit est d’éviter la surutilisation automatisée des ressources, qui est généralement le fait de bots capables d’envoyer des centaines ou des milliers de requêtes simultanées chaque seconde. La limitation du débit peut également vous aider à bloquer toute attaque DDoS lancée par ces bots.

La plupart des frameworks de développement web fournissent des intergiciels de limitation de débit prêts à l’emploi et faciles à configurer. Même si votre framework ne dispose pas d’un intergiciel, vous pouvez en obtenir un via une bibliothèque tierce et le configurer assez rapidement.

En dehors de la recherche de bots, c’est aussi une bonne pratique de limiter le nombre autorisé de requêtes ou de données récupérées à un nombre raisonnable. Cela permet d’éviter une surutilisation involontaire des ressources qui peut être déclenchée par des erreurs manuelles telles que les boucles infinies. Cela permet également d’offrir à vos utilisateurs une disponibilité uniforme – un pic d’utilisation d’un utilisateur n’affecte pas l’expérience des autres utilisateurs.

Mesures d’authentification de l’API

Chaque fois que vous construisez une API orientée vers le public, vous devez mettre en œuvre des mesures d’authentification pour éviter les abus et les mauvaises utilisations de vos services. Une bonne option est le système OAuth2.

Le système OAuth2 divise votre compte en ressources et vous permet de fournir un accès contrôlé aux porteurs de jetons d’authentification. Vous pouvez définir ces jetons pour qu’ils expirent à des durées données – disons 24 heures – après quoi ils seront rafraîchis. Ainsi, même si votre jeton fait l’objet d’une fuite, la fenêtre d’utilisation limitée réduira l’impact de la fuite.

Une partie essentielle de la sécurité des API est l’utilisation de clés d’API pour authentifier les requêtes. Vous pouvez définir des clés d’API pour limiter le taux d’appels à votre API et réduire les risques d’attaques DoS. Si vous proposez un service d’API payant, vous pouvez utiliser des clés d’API pour fournir un accès basé sur les plans que chaque utilisateur a achetés.

Vous devriez également envisager d’équiper les points de terminaison de vos employés internes d’une authentification multi-facteurs, d’un logiciel antivirus et de mises à jour automatiques des applications. Ces mesures simples contribueront grandement à garantir qu’il n’y ait aucune brèche dans la qualité des services que vous offrez.

Validation des entrées

Bien que cela semble être une chose évidente à faire lors de la création d’une application logicielle, un nombre surprenant d’APIs ne l’implémentent pas correctement. La validation des entrées ne consiste pas seulement à vérifier que les données entrantes ont un format correct, mais aussi à éviter les surprises.

L’un des exemples les plus simples, mais les plus courants, est l’injection SQL. Ne pas s’en prémunir peut anéantir toute votre base de données si la mauvaise requête est exécutée. Veillez à valider les données d’entrée pour vérifier qu’elles ont le bon format et à supprimer les caractères qui pourraient révéler une intention malveillante.

Un autre élément à surveiller est la taille de la requête. Dans le cas des requêtes POST, tenter d’accepter et d’analyser une entrée extrêmement volumineuse ne fera qu’épuiser votre API. Vous devez toujours vous concentrer sur la validation de la taille d’une requête POST en premier lieu et renvoyer un code et un message d’erreur appropriés au client, le cas échéant.

Filtrage d’adresse IP

Si vous proposez des services B2B et que vos clients utilisent votre API à partir d’emplacements définis dans le monde entier, vous devriez envisager d’ajouter une couche de sécurité supplémentaire à vos systèmes en limitant les adresses IP qui accèdent à votre API, en fonction de leur emplacement.

Pour les nouveaux sites et clients, vous devrez ajouter leurs données à votre liste de « sites autorisés » Bien que cela puisse ajouter des frictions supplémentaires au processus d’intégration de vos clients, cela contribuera grandement à améliorer la sécurité et, par conséquent, la qualité de leur expérience.

Pour minimiser davantage les risques de sécurité, vous devriez également envisager de limiter les autorisations et l’accès des clients au strict minimum nécessaire pour les opérations standard. De même, limitez votre accès HTTP pour vous assurer que les clients mal configurés ne reçoivent rien de plus que les spécifications de l’API et le code d’accès. Assurez-vous que votre API rejette ces requêtes avec un code de réponse 405.

Il est intéressant de noter qu’une grande partie des cyber-attaques dans le monde proviennent d’un nombre limité de pays. Une autre bonne pratique consiste à bloquer entièrement l’accès à vos ressources à partir de ces endroits si vous n’y avez pas de clients.

De plus, si vous détectez une attaque, commencez par bloquer les requêtes GET/POST provenant de la région de l’attaquant. La possibilité de restreindre les requêtes HTTP en fonction de l’emplacement des clients est l’un des moyens les plus rapides de contrer une cyber-attaque en cours.

XDR (Détection et réponse étendues)

La plupart des organisations déploient des outils de sécurité traditionnels tels que des pare-feu et des techniques de protection/détection des intrusions. Bien que ceux-ci soient rudimentaires à tout système de sécurité, ils ne sont pas conçus explicitement pour les API.

Une nouvelle technologie appelée XDR (Extended Detection and Response) offre une approche meilleure et plus holistique de la protection de l’ensemble de vos environnements informatiques, y compris de vos points de terminaison d’API. XDR fournit aux équipes de sécurité des alertes en temps réel sur les comportements malveillants, ce qui leur permet d’enquêter rapidement sur les attaques.

Voici quelques façons dont XDT sécurise les points de terminaison d’API :

• Surveillance HTTPS : XDR peut gérer les certificats de sécurité de vos points de terminaison et inspecter également les communications HTTP. Lorsqu’il détecte une anomalie, il peut rapidement mettre fin à la connexion ou prendre d’autres mesures automatisées.
• Surveillance des appels API : XDR peut suivre le nombre d’appels API effectués par vos clients et avertir vos équipes de sécurité lorsqu’il détecte des tendances suspectes, même dans les limites de débit fixées.
• Jeton web JSON (JWT) : JWT est une méthode standard utilisée pour représenter de manière sécurisée l’identité d’un utilisateur lorsqu’il communique sur un réseau. XDR peut aider à identifier les utilisateurs via JWT sur vos réseaux sans avoir à transmettre d’informations d’identification. Cela vous permet d’identifier les comptes utilisateurs dans votre trafic API et d’analyser leur comportement à la recherche d’anomalies.
• Filtrage des adresses IP : XDR s’intègre bien aux bases de données de renseignement sur les menaces et vérifie les requêtes entrantes pour détecter les adresses IP ou les origines légitimes.
• Validation des entrées : Même si vous n’avez pas mis en place de mesures appropriées de validation des entrées dans votre service, les solutions XDR peuvent analyser automatiquement les requêtes SQL ou d’autres requêtes sensibles aux bases de données pour détecter les attaques par injection, les arrêter dans leur élan et en informer les équipes de sécurité.

Routines de maintenance

Il existe quelques routines de maintenance générales que vous pouvez mettre en place pour améliorer la qualité de la sécurité de vos API. En voici quelques-unes :

• Nettoyez les données : Supprimez les données redondantes des utilisateurs et des employés de vos services. Le nettoyage régulier des données est non seulement une bonne pratique, mais il permet également de diminuer les risques de perte ou de corruption accidentelle des données.
• Effectuez des mises à jour régulières : N’oubliez pas de mettre régulièrement à jour votre pile technologique et vos certifications de service. Vous devez mettre en œuvre des correctifs de routine pour vos services de points de terminaison, et toutes vos licences doivent refléter les dernières normes réglementaires et de conformité.
• Révisez les mesures de sécurité : Maintenez vos plans de sécurité et de récupération à jour. Ils doivent refléter les derniers changements ou ajouts à votre infrastructure réseau aussi fréquemment que possible. Si vous ajoutez régulièrement de nouvelles ressources mobiles, IoT ou autres ressources sur site, cette pratique est encore plus critique.

Surveillance des points de terminaison d’API

Maintenant que vous avez compris comment construire, consommer et sécuriser les points de terminaison d’API, la prochaine chose essentielle à savoir est de les surveiller. La surveillance est un concept crucial appliqué à toute la dynamique de l’ingénierie logicielle pour analyser et renforcer la croissance des produits techniques.

Conseils, astuces et meilleures pratiques

Dans le cas des points de terminaison d’API, la surveillance peut vous aider à sécuriser et à optimiser vos points de terminaison pour de meilleures performances et une plus grande fiabilité. La section suivante vous présentera certaines des meilleures pratiques à suivre lors de l’instrumentation et de la surveillance des points de terminaison d’API.

1. Validez la disponibilité fonctionnelle

En général, les équipes ont tendance à surveiller la disponibilité ou le temps de fonctionnement de l’API et à le considérer comme la norme pour mesurer la qualité du service API. Cependant, mesurer uniquement la disponibilité globale de l’API n’est pas suffisant pour les différents types de transactions d’échange de données qui se produisent via l’API. Vous devez surveiller la disponibilité et les performances de tous les verbes (Créer, Lire, Mettre à jour, Supprimer, etc.) individuellement pour vous assurer qu’ils sont tous opérationnels.

Pour ce faire, vous pouvez mettre en œuvre des outils de surveillance synthétiques avec des moniteurs API à plusieurs étapes. Cela vous aidera à améliorer simultanément la disponibilité de l’API et des données. En même temps, vous devez vous rappeler que la surveillance synthétique utilise un ensemble limité et prédéfini d’appels d’API pour les tests. Ainsi, le trafic réel du monde réel peut différer des entrées de l’ensemble dans la surveillance synthétique.

2. N’oubliez pas de surveiller les dépendances des API

Chaque API n’est pas construite indépendamment. Le plus souvent, vous devez consommer des API tierces tout en construisant la vôtre. Et si vous pouvez instrumenter votre code jusqu’à ses niveaux les plus profonds, vous pouvez facilement oublier de suivre le comportement de ces API tierces.

Par conséquent, vous devez également suivre les réponses des API tierces. D’après notre expérience, les dépendances défectueuses ont créé beaucoup de remous chaque fois que nous avons omis de les analyser indépendamment.

3. Implémentez des tests automatisés dans la surveillance des API

Si vous avez mis en place un pipeline CI/CD bien défini, vous connaissez probablement déjà l’importance de l’automatisation. Il est donc préférable que vous puissiez mettre en place des tests automatisés pour vos points de terminaison d’API en même temps que la surveillance. Vous devriez envisager d’ajouter une étape supplémentaire dans vos pipelines CI/CD pour exécuter des tests automatisés sur vos points de terminaison avant une publication. Bien que cela soit devenu une norme à l’heure actuelle, vous devriez vérifier si vous l’avez mis en œuvre ou non.

4. Choisissez un outil doté d’une solide fonctionnalité d’alerte

Avec la variété d’outils disponibles sur le marché actuel, il peut être difficile de trouver celui qui convient à votre cas d’utilisation. Pour faciliter votre recherche, voici une règle rapide à retenir : Recherchez toujours de solides capacités d’alerte. Si l’outil que vous avez choisi ne vous alerte pas correctement sur les problèmes entrants, vous devrez perdre du temps à intervenir systématiquement pour vérifier si des événements se sont produits. L’automatisation dans ce domaine contribue grandement à accroître la productivité de votre équipe.

5. Donnez la priorité aux outils qui sont directement intégrables dans votre pipeline CI/CD

Vous devriez envisager d’intégrer la surveillance à chaque étape de vos pipelines CI/CD pour analyser l’efficacité de vos processus DevOps. Pour cela, vous devez sélectionner avec soin les outils qui offrent une telle fonctionnalité.

Pour vérifier si l’outil que vous avez choisi en dispose, consultez la liste des intégrations tierces fournies. Si votre serveur CI, tel que Jenkins ou GitHub, est pris en charge par l’outil, vous êtes prêt !

6. Ne faites jamais de compromis sur la confidentialité des API

Certains outils de surveillance d’API s’appuient sur des plateformes SaaS tierces qui obligent les clients à ouvrir certains ports sur leurs pare-feu pour surveiller des API internes autrement inaccessibles. Ceux-ci présentent toutefois un risque de sécurité majeur. Toute personne ayant connaissance de ces ports peut les utiliser pour obtenir un accès non autorisé à vos systèmes.

C’est pourquoi il est impératif de choisir une bonne solution de surveillance des API qui tienne compte de la conception de vos API et vous permette de surveiller chaque point de terminaison, qu’il soit interne ou externe, en toute sécurité. Les meilleurs outils à cet effet sont ceux qui peuvent accéder à vos API internes de manière privée sans laisser de place aux intrus.

7. Surveillez 24/7

Ne pas surveiller vos API, littéralement tout le temps, peut vous coûter une fortune. Tout service peut tomber en panne à n’importe quel moment. Et si votre service de surveillance est désactivé à ce moment-là, vous devrez attendre que le service se rétablisse pour savoir que la panne a eu lieu. Vous pouvez perdre de précieuses affaires dans cette période.

Par conséquent, nous vous suggérons de mettre en place des moniteurs à haute fréquence qui s’exécutent au moins cinq fois par heure pour les tests fonctionnels, et une fois par heure pour la surveillance de la sécurité et d’OAuth.

8. Préférez la surveillance externe à la surveillance interne

Bien souvent, les problèmes ne se produisent pas uniformément en interne et en externe. Vos utilisateurs peuvent être confrontés à un problème que vous ne pouvez pas reproduire à l’intérieur des pare-feu de votre système. Dans ce cas, peu importe que vos mesures internes fonctionnent correctement ; l’utilisateur ne peut pas accéder à votre produit, donc chaque mesure opérationnelle n’est d’aucune utilité.

Pour éviter de tels scénarios, préférez toujours une configuration de surveillance externe à une configuration interne. Pour résoudre les problèmes rencontrés par vos utilisateurs, vous devez examiner vos API du point de vue de l’utilisateur.

9. Surveillez toutes les ressources

Au cours du processus de construction du service ou de l’application derrière votre API, vous pouvez concevoir certains composants de base ou complexes. S’il peut être tentant de faire l’impasse sur la surveillance des composants essentiels, ce n’est pas une bonne pratique dans tous les cas. Bien souvent, une erreur apparemment insignifiante dans un composant simple et sans importance peut briser une application étendue.

Si vous n’avez pas des yeux partout, vous serez obligé de perdre des heures à essayer de trouver le composant qui a causé le problème, pour découvrir que la petite pièce que vous considériez comme trop innocente pour être défectueuse est en fait le coupable.

10. Analysez tous les paramètres de réponse

Vérifier uniquement que le code d’état a retourné 200 n’est pas suffisant. La plupart des développeurs utilisent les codes d’état HTTP de base, tels que 200 pour le succès et 500 pour l’erreur du serveur, pour désigner les réponses génériques. Cependant, le succès ou l’erreur peuvent prendre diverses formes, et le suivi de chaque instance de celles-ci est essentiel pour déterminer les performances de vos API.

Vous devriez également envisager de rechercher des changements dans la taille du contenu renvoyé par les API. Si la réponse habituelle est d’une taille de 500 ko, mais que vous n’avez reçu que 100 ko ou moins, vous avez probablement rencontré un certain type d’échec.

Outils de surveillance d’API

Pour mettre en œuvre les meilleures pratiques mentionnées ci-dessus, vous devez commencer par une solution de surveillance des API. Bien qu’il existe des extensions prêtes à l’emploi dans des frameworks comme WordPress pour la surveillance des API, vous devez rechercher une solution plus complète dans le cas d’applications purement codées.

Dans la section suivante, nous examinerons une courte gamme d’outils de surveillance d’API en vogue pour vous aider à démarrer avec un minimum de coûts et d’efforts.

Uptrends

Uptrends offre une surveillance pour les applications web, les API, les serveurs, et bien plus encore. Elle dispose d’une vaste base de clients de plus de 25.000 petites et grandes organisations, dont certains noms éminents comme Microsoft, Vimeo et Volkswagen.

Une caractéristique frappante que ce fournisseur offre est le test basé sur le navigateur. Il utilise des navigateurs réels et uniques pour exécuter vos applications et sites web et capturer des métriques détaillées sur leurs performances.

Toutefois, les temps de réponse et les mesures ne sont pas les seules caractéristiques de ce service. Avec Uptrends, vous obtenez également un rapport de performance détaillé sur chacune de vos ressources afin de comprendre tous les types de goulots d’étranglement possibles dans votre système. Pour chaque erreur, Uptrends prend une capture d’écran et vous l’envoie afin que vous puissiez vivre l’erreur telle qu’elle s’est produite.

Dotcom-Monitor

Dotcom-Monitor est fier de permettre aux utilisateurs de configurer un dispositif de surveillance multi-tâche à l’aide d’une tâche HTTP ou HTTPS. Cela vous permet de surveiller la disponibilité, les réponses appropriées et les performances des API web.

Les agents Dotcom-Monitor répliquent une ou plusieurs requêtes de clients pour vérifier si les données peuvent être échangées de manière adéquate entre l’API et les clients. Lorsque l’un des agents détecte une erreur, il vérifie l’erreur par rapport à une liste de filtres prédéfinis. Si l’erreur n’est pas définie pour être filtrée, l’agent déclenche une alerte.

L’outil vous permet de configurer des calendriers d’alerte personnalisés et des alternatives d’escalade. Vous pouvez exporter les rapports d’erreur dans divers formats, notamment CSV, PDF, TXT, etc. Les rapports d’erreur de Dotcom-Monitor montrent différentes mesures précieuses telles que les temps d’arrêt, les temps de réponse et les performances moyennes par emplacement.

Dotcom-Monitor fait partie des solutions de surveillance d’API les plus abordables, et ses plans commencent à partir de 1,99 $ par mois. Si vous êtes une organisation en pleine croissance avec un budget limité, Dotcom-Monitor pourrait être la solution de surveillance d’API qu’il vous faut.

Graphite

Graphite est un système de surveillance d’API open source qui vous permet de capturer des mesures à partir d’API en demandant au service de pousser les données dans le composant Carbon de Graphite. Graphite stocke ensuite ces données dans une base de données pour en tirer des enseignements.

Graphite est populaire parmi ses utilisateurs pour la simplicité qu’il offre dans le processus d’installation, qui comprend un script d’installation et de configuration automatisé pour sa pile, connu sous le nom de Synthesize.

Une autre caractéristique frappante offerte par Graphite est la possibilité de stocker des événements arbitraires. Ces événements sont généralement liés à des mesures de séries temporelles. Vous pouvez également ajouter et suivre les déploiements d’applications ou d’infrastructures au sein de Graphite, ce qui permet à votre équipe de développement de trouver plus rapidement la source des problèmes et des goulets d’étranglement et d’obtenir plus de contexte sur les événements et les anomalies qui entraînent un comportement inattendu.

Sematext

Sematext est une solution populaire parmi les équipes DevOps, en raison de la suite d’outils de surveillance qu’elle offre. La surveillance des API fait partie de son service de surveillance synthétique, qui est connu sous le nom de Sematext Synthetics.

Sematext fournit un système complexe de surveillance et d’alerte API que vous pouvez personnaliser pour qu’il fonctionne en fonction de diverses erreurs et mesures. Vous pouvez configurer cet outil pour effectuer une double ou triple vérification avant d’envoyer une alerte. Cela peut vous aider à éliminer les faux positifs de vos alertes et à fournir des informations plus précises et plus pertinentes.

Outre le puissant moniteur HTTP que propose Sematext, vous disposez également d’une fonction complète de surveillance du navigateur. Elle vous permet de collecter des mesures de performance web basées sur les interactions pré-scriptées des utilisateurs avec vos applications web. Cela signifie que vous pouvez aller au-delà des normes de test habituelles de suivi des temps de chargement des pages etc., et jeter un coup d’œil plus approfondi aux interactions détaillées de l’utilisateur émulé, telles que le flux d’authentification in-app, l’exécution de la requête de recherche, ou l’ajout ou le retrait d’articles d’un panier. Sematext propose d’emblée plusieurs interactions utilisateur de ce type.

BlazeMeter

Blazemeter est une solution de test et de surveillance de bout en bout de premier ordre pour les applications modernes. L’outil vous donne une liberté totale dans le choix des frameworks de test open source et leur analyse à l’aide de tableaux de bord simples. Il offre également une intégration transparente avec Apache JMeter, qui figure parmi les meilleurs outils de mesure des performances pour les applications web complexes.

Comme la plupart des solutions de surveillance des API, BlazeMeter offre également des fonctionnalités fondamentales comme les tests fonctionnels (appelés « scénarios »), que vous pouvez configurer à l’aide d’une interface utilisateur graphique interactive. BlazeMeter a exposé un DSL (Domain Specific Language) à travers son outil de test dédié Taurus qui permet aux développeurs d’écrire des tests génériques. Vous pouvez ensuite exécuter ces tests avec JMeter et d’autres outils open source populaires.

Compte tenu de sa conception lourde, le prix de BlazeMeter est plus élevé. Si votre application compte plus de 5 000 utilisateurs simultanés, vous devez être prêt à débourser plus de 600 $ par mois. Vous pouvez toutefois opter pour des plans à coût fixe en fonction de votre utilisation.

Si votre produit se situe dans la lignée de Pfizer, Adobe, NFL, Atlassian, etc., BlazeMeter est la solution de surveillance API parfaite pour vous.

Bien qu’il s’agisse d’une collection plutôt concise d’outils de surveillance d’API, il existe de nombreuses autres options intéressantes. Assurez-vous de consulter la collection détaillée d’outils de surveillance d’API de Geekflare et le guide d’achat complet pour les outils de surveillance d’API de Sematext avant de faire votre choix !

Résumé

Les API sont l’épine dorsale des machines informatiques modernes. La plupart des produits sur le marché des logiciels sont accompagnés d’une API pour offrir une intégration transparente avec des entités tierces. Pour offrir une expérience utilisateur fluide et fidéliser vos clients, vous devez envisager de créer et de fournir une API avec votre produit logiciel… ce qui signifie que vous devez connaître les API à fond.

Ce guide a été conçu pour vous aider à percer dans ce domaine en vous présentant les bases de cette technologie, notamment en illustrant les concepts de base, les meilleures pratiques et les outils utiles de surveillance des API sur le marché. Avec un peu de chance, vous avez maintenant une meilleure compréhension de la façon dont les ressources web communiquent entre elles.

Cependant, malgré tout ce dont nous avons parlé, nous n’avons fait qu’effleurer la surface en ce qui concerne tout ce que les API et les points de terminaison d’API peuvent accomplir. Continuez à lire, à tester et à vous rapprocher de la communauté de développement pour étendre vos connaissances et vos compétences en matière de points de terminaison d’API.