L’API REST (Interface de programmation d’applications pour le transfert d’état représentatif) est un style architectural qui permet aux logiciels de communiquer entre eux sur un réseau ou sur le même appareil. Les développeurs utilisent souvent des API REST pour créer des services web. Ces services, communément appelés services web RESTful, utilisent les méthodes HTTP pour récupérer et publier des données entre un appareil client et un serveur.
En utilisant le protocole HTTP, les API REST permettent à des logiciels d’un appareil de communiquer avec des logiciels d’un autre appareil (ou du même appareil), même si ces derniers utilisent des systèmes d’exploitation et des architectures différentes. Le client peut demander des ressources dans un langage compris par le serveur, qui renverra la ressource dans un langage accepté par le client. Les formats de réponse les plus courants sont JSON (JavaScript Object Notation), XML (Extensible Markup Language) ou texte, bien que de nombreux autres langages soient pris en charge par les API.
Qu’est-ce que l’architecture REST ?
REST est un ensemble de principes directeurs auxquels un développeur doit adhérer pour que son API puisse être considéré comme “RESTful”. Ces principes ne spécifient pas la manière de mettre en œuvre l’API.
Architecture client-serveur : Les clients de l’API utilisent les appels HTTP pour demander (méthode GET) ou envoyer (méthode POST) des données au serveur, ou utiliser d’autres méthodes HTTP prises en charge par l’API. Les méthodes GET et POST sont les plus couramment utilisées, mais d’autres méthodes comme HEAD, PUT, PATCH, DELETE, CONNECT, OPTIONS et TRACE peuvent également être prises en charge par l’API. La documentation de l’API indique les méthodes disponibles. Pour en savoir plus, consultez le site w3schools.com.
Sans état : Une application sans état ne conserve pas de connexion ni n’enregistre d’informations entre deux requêtes du même client. Le client envoie une requête, l’API exécute l’action définie dans la requête et répond. Une fois la réponse envoyée, l’API se déconnecte et ne conserve aucune information sur le client en mémoire. L’API traite chaque requête comme une nouvelle demande.
Avec mise en cache : Une API REST doit normalement permettre la mise en cache des données souvent demandées. Pour réduire la bande passante, la latence et la charge du serveur, une API doit pouvoir identifier les ressources pouvant être mises en cache, déterminer qui peut les mettre en cache et décider combien de temps elles peuvent rester en cache.
Interface uniforme : Le client interagit avec le serveur de manière définie, indépendamment de l’appareil ou de l’application.
Identification des ressources : Chaque ressource de l’API doit avoir un URI (Uniform Resource Identifier) spécifique, tel que /monitor/{monitorGuid} dans l’API Uptrends version 4.
Auto-descriptif : L’API comprend des métadonnées, telles que le Content-Type, qui décrivent la façon d’interpréter la réponse. Pour en savoir plus sur les types MIME, consultez le site w3schools.com.
HATEOAS (Hypermedia As The Engine Of Application State) : La réponse du serveur contient des URI de méthodes supplémentaires auxquelles le client peut accéder en utilisant les données de la réponse. Pour en savoir plus sur HATEOAS, consultez le site w3schools.com.
Système en couches : Une API peut être composée de plusieurs couches, telles que des serveurs proxy ou des dispositifs de répartition de charge. Le serveur final peut déployer des serveurs supplémentaires pour formuler une réponse. Le client ne sait pas quel serveur répond à sa requête. Ce système en couches rend l’API plus scalable.
Code à la demande (optionnel) : L’API peut envoyer un code exécutable, tel que des applets Java ou JavaScript.
Qu’est-ce qu’une ressource web ?
Une ressource web est essentiellement tout élément avec lequel un client peut interagir sur le web. Ce terme peut faire référence à un fichier tel qu’un document Word, une image, du HTML ou une vidéo. Cependant, une ressource peut également être plus abstraite et inclure des éléments réels. Elle peut également être un service, comme Google Maps ou des services financiers.
Le développeur de l’API décide des formats pris en charge pour les réponses. Par exemple, un serveur peut renvoyer des réponses au format JSON, XML ou texte. L’API doit pouvoir formater la réponse en fonction des besoins du client.
Exemples d’API REST
Presque toutes les activités sur Internet impliquent des API. Celles-ci travaillent en arrière-plan pour effectuer des tâches telles que la validation d’adresses, le traitement des cartes de crédit ou encore la réservation et la planification de rendez-vous.
Le service postal des États-Unis propose une API qui permet aux entreprises de gérer leurs besoins postaux, comme la validation des adresses, la récupération des codes postaux, le calcul des frais de port, le suivi des envois, la génération d’étiquettes d’expédition et la planification de la collecte du courrier.
Les grands magasins Macy’s fournissent une API à leurs partenaires, qui peuvent rechercher des produits dans l’inventaire de Macy’s, interagir avec les registres de cadeaux, vérifier les événements en magasin et obtenir des coupons.
L’API des théâtres AMC permet aux développeurs d’applications tierces d’accéder à leur système de réservation pour consulter les horaires, acheter des billets et commander des services.
L’API Graph de Facebook permet aux applications d’interagir avec l’application Facebook, notamment pour publier des messages, gérer des publicités et collecter des données.
Un point important à retenir est que les API peuvent elles-mêmes utiliser d’autres API. Par exemple, l’API des théâtres AMC utilise une autre API pour traiter les paiements par carte de crédit.
Maintenir la disponibilité et la rapidité des API
Les utilisateurs d’API dépendent de ces dernières pour le bon fonctionnement de leurs sites web, de leurs applications et de leurs appareils. Les API indisponibles ou lentes peuvent entraîner des défaillances et des frustrations chez les utilisateurs. Les fournisseurs d’API, ainsi que les consommateurs, doivent surveiller les problèmes et intervenir rapidement en cas de panne ou de baisse de performances.
Surveillance de la disponibilité de l’API
Même une brève interruption peut entraîner des pannes de sites web, d’applications et d’appareils. Les éditeurs d’API doivent s’assurer que leur système dispose de la redondance nécessaire pour éviter les interruptions, même si celles-ci peuvent survenir. Les éditeurs d’API ont la responsabilité de maintenir une disponibilité continue pour leurs utilisateurs. Ces derniers ont tout intérêt à protéger leur activité et leurs utilisateurs en surveillant les API essentielles à leurs services. La surveillance API synthétique propose deux solutions : la surveillance multi-étapes de l’API et la surveillance de la disponibilité du service web.
Vérification de la disponibilité et des performances de base des API
Une surveillance performante exige des tests fréquents. Pour maintenir une disponibilité élevée, les tests doivent être effectués toutes les minutes. Un simple moniteur de service web HTTPS/HTTP est idéal pour vérifier la disponibilité.
- Effectuer des vérifications toutes les minutes.
- Effectuer des vérifications depuis différents emplacements dans le monde.
- Prendre en charge l’authentification de base.
- Mesurer le temps de réponse.
- Vérifier le contenu de la réponse.
- Vérifier des codes de réponse spécifiques.
La surveillance de la disponibilité garantit que l’API répond à la demande et fournit des informations sur le temps de réponse. Grâce à la vérification du contenu et des codes de réponse, vous pouvez vérifier si l’API renvoie le résultat attendu. En cas d’erreur, le système d’alerte informe l’équipe en charge du problème. De plus, les rapports du moniteur fournissent les données nécessaires pour étayer tout accord de niveau de service.
Mettre en place des moniteurs de service web pour chaque point de terminaison garantit leur disponibilité. Cependant, ces vérifications peuvent ne pas suffire à prouver le bon fonctionnement d’une API. La surveillance multi-étapes de l’API permet de gérer des vérifications plus complexes.
Surveillance avancée des API
Un test approfondi d’une API nécessite de gérer des scénarios plus complexes, tels que des redirections, la validation des données et la réutilisation de ces dernières. La surveillance multi-étapes de l’API élève la surveillance de la disponibilité à un niveau supérieur.
- Gérer les redirections.
- Prendre en charge les authentifications de base, NTLM (Windows) et Digest.
- Utiliser des certificats clients.
- Déclarer des variables : prédéfinies, assigner des valeurs depuis le corps de la réponse, utiliser des variables automatiques.
- Réutiliser des valeurs dans des requêtes ultérieures.
- Utiliser des opérateurs de comparaison et effectuer des assertions sur le contenu des réponses et les performances.
- Capturer des valeurs numériques de la réponse pour les rapports.
La surveillance multi-étapes de l’API permet de vérifier la fonctionnalité complète des transactions de l’API, fournit des données de performances pour l’ensemble de la transaction et mesure également la rapidité des requêtes individuelles.
Points clés
L’API REST est un style architectural qui permet aux logiciels de communiquer, quels que soient les systèmes d’exploitation utilisés.
Les API REST fonctionnent selon une relation client/serveur, en fournissant une interface uniforme.
Une API REST possède une interface uniforme basée sur des ressources, elle est auto-descriptif et utilise HATEOAS.
HATEOAS (Hypermedia As The Engine Of Application State) signifie que la réponse de l’API contient des données permettant d’accéder à d’autres méthodes disponibles.
Les API REST sont sans état, ce qui signifie que le serveur ne conserve pas de connexion ou de session entre les appels.
Les API REST utilisent une architecture multicouche pour faciliter l’évolutivité.
Maintenir une disponibilité élevée et des réponses rapides est essentiel pour une API REST.
La surveillance de l’API vérifie la disponibilité et les performances, et envoie des notifications en cas de problèmes.
Les moniteurs HTTPS/HTTP de service web sont excellents pour surveiller la disponibilité.
La surveillance multi-étapes de l’API permet de vérifier les interactions complètes de l’API en termes de disponibilité, de fonctionnalité et de performances.
