Les API sont très importantes pour tous ceux qui créent des logiciels et nous parlons beaucoup de nos API SMS! Revenons donc aux bases du développement, avec tout ce que vous devez savoir sur les API.
Et mieux encore, nous avons demandĂ© Ă un expert d’en parler. Lisez donc tout ce que vous devez savoir sur les API dans la programmation.
Les interfaces de programmation d’applications (API) sont un aspect de plus en plus crucial du dĂ©veloppement de logiciels, en particulier Ă mesure que l’infrastructure se complexifie. Les systèmes logiciels utilisent des API pour partager des donnĂ©es et permettre aux diffĂ©rents composants d’un système de fonctionner ensemble.
Vous pouvez Ă©galement utiliser les API pour injecter dans votre système des connaissances et des donnĂ©es spĂ©cialisĂ©es provenant d’autres systèmes, sans avoir Ă les intĂ©grer vous-mĂŞme. Par exemple, si votre application de fitness propose aux utilisateurs un programme hebdomadaire de course Ă pied, vous pouvez intĂ©grer une API qui fournit une fonctionnalitĂ© de service de messages courts (SMS). L’API permet Ă votre application d’envoyer des rappels aux utilisateurs sur le moment oĂą ils doivent courir.
Cet article explique ce que sont les API et les avantages qu’elles offrent. Vous y trouverez Ă©galement des conseils et des bonnes pratiques sur la manière de concevoir et d’utiliser les API de manière plus efficace.
Qu’est-ce qu’une API ?
ConsidĂ©rez une API comme un messager ou un intermĂ©diaire. L’interface permet Ă diffĂ©rents logiciels de communiquer entre eux selon des règles et des protocoles dĂ©finis. Parce qu’une API relie les diffĂ©rents composants d’un système, elle rend le dĂ©veloppement d’applications plus fluide et plus souple. Vous pouvez ajouter ou mettre Ă jour un service sans avoir Ă Ă©crire tout le code vous-mĂŞme.
Parce que les API peuvent vous aider Ă dĂ©velopper vos systèmes logiciels, elles offrent de multiples avantages Ă votre entreprise. Voici quelques exemples de cas d’utilisation.
Permettre le partage des données
L’un des principaux avantages des API est qu’elles permettent aux applications de votre organisation de partager des donnĂ©es.
Par exemple, supposons que votre organisation dispose d’un système central de ressources humaines qui contient les donnĂ©es des employĂ©s (nom, prĂ©nom, date de naissance, etc.), mais que vous ayez d’autres systèmes de gestion des voyages et de paie qui ont besoin d’informations sur les employĂ©s. Vous pouvez utiliser les API du système RH pour vous connecter aux systèmes de gestion des voyages et de paie afin de partager les donnĂ©es nĂ©cessaires sur les employĂ©s. De cette manière, le système RH fait office de source unique de vĂ©ritĂ© pour vos donnĂ©es. Si vous deviez conserver plusieurs copies des donnĂ©es des salariĂ©s dans chaque système sĂ©parĂ©ment, il serait difficile d’actualiser constamment ces donnĂ©es dans tous les systèmes.
Accroître les opportunités commerciales
Un autre avantage des API est que vous pouvez les utiliser comme mĂ©canisme pour exposer, ou mettre Ă disposition, vos services internes au monde extĂ©rieur. Cela peut offrir d’Ă©normes opportunitĂ©s financières Ă votre entreprise.
Un exemple en est le widget de demande de trajet Uber, que les dĂ©veloppeurs peuvent ajouter Ă leurs applications pour demander des rĂ©servations Uber. Le widget utilise les API d’Uber pour effectuer les rĂ©servations. Grâce Ă ce widget, Uber pĂ©nètre massivement le marchĂ© en multipliant les canaux de distribution de ses services. Si Uber avait limitĂ© ses API Ă un usage interne, elle aurait manquĂ© ce moyen supplĂ©mentaire de croissance commerciale.
Permettre des intégrations multiplateformes
Dans l’Ă©cosystème informatique actuel, il est courant que les systèmes soient construits avec plusieurs langages de programmation, tels que Python ou Java, et hĂ©bergĂ©s sur plusieurs systèmes d’exploitation tels que Windows ou Linux. Si ces diffĂ©rents composants devaient communiquer directement, ce serait presque impossible.
Les API vous offrent un protocole de communication unifiĂ© pour rĂ©soudre ce problème. Grâce Ă des protocoles dĂ©finis par l’industrie, diffĂ©rents systèmes conçus dans diffĂ©rents langages de programmation peuvent communiquer facilement et sans confusion.
Contrôle des données et de la propriété intellectuelle
Un autre avantage de l’utilisation des API est que vous pouvez protĂ©ger et contrĂ´ler votre propriĂ©tĂ© intellectuelle. Au lieu d’exposer tous les dĂ©tails de la mise en Ĺ“uvre de votre logique d’entreprise aux consommateurs externes (ce qui risque de vous faire perdre votre avantage concurrentiel), vous ne rĂ©vĂ©lez que le cĂ´tĂ© entrĂ©e de votre API.
OpenAI y parvient grâce Ă ses API GPT-3. GPT-3 est un modèle d’intelligence artificielle qui peut gĂ©nĂ©rer du contenu avec une structure linguistique avec une grande prĂ©cision. OpenAI n’expose pas les modèles GPT-3 aux utilisateurs. En revanche, l’exposition des modèles en tant qu’API permet Ă OpenAI de mieux contrĂ´ler l’utilisation des modèles. En cas de violation de l’utilisation, OpenAI peut facilement rĂ©voquer l’accès Ă l’API, et l’utilisateur fautif est immĂ©diatement bloquĂ©.
Comment fonctionnent les API ?
Maintenant que vous connaissez certains des avantages de l’utilisation des API, voici plus de dĂ©tails sur le fonctionnement de ces interfaces.
Serveurs et clients
L’utilisation d’une API implique deux parties. Le serveur de l’API est le système dorsal qui met l’API Ă disposition. Le client de l’API, ou consommateur, est l’application qui utilise l’API.
![Graphique de base du client API et du serveur API](https://i.imgur.com/pCYjXtc.png?format=webp)
Types d’API
Il existe de nombreux protocoles API. Les types les plus courants sont détaillés ci-dessous.
Transfert d’Ă©tat reprĂ©sentationnel (REST)
REST est le type d’API le plus connu, rĂ©putĂ© pour sa facilitĂ© d’utilisation. Il met Ă disposition les donnĂ©es de l’arrière-plan dans des formats simples tels que JSON et XML. Les types de requĂŞtes HTTP les plus couramment utilisĂ©s avec les API REST sont les suivants :
- GET : Pour lire une ressource
- POST : Pour créer une nouvelle ressource
- DELETE : Pour supprimer une ressource
- PUT : Pour mettre Ă jour une ressource
Appel de procédure à distance (RPC)
Le protocole RPC permet l’exĂ©cution d’une fonction dans un contexte donnĂ© Ă partir d’une autre fonction dans un contexte diffĂ©rent. Cela revient Ă appeler une fonction locale de votre programme Ă partir d’une autre fonction. La diffĂ©rence est que le protocole RPC fonctionne dans le contexte HTTP pour permettre un “appel Ă distance”. Le protocole RPC a gagnĂ© en popularitĂ© grâce Ă ses performances Ă©levĂ©es. Une amĂ©lioration rĂ©cente de ce protocole est gRPC, dĂ©veloppĂ© par Google.
Protocole d’accès simple aux objets (SOAP)
SOAP est une norme de communication web basĂ©e sur XML et sur HTTP. Ce protocole communique par le biais de messages constituĂ©s d’une balise enveloppe contenant le message, d’un corps (pour la demande ou la rĂ©ponse) et d’un en-tĂŞte pour toute information supplĂ©mentaire. Le protocole SOAP est indĂ©pendant du langage, avec une gestion intĂ©grĂ©e des erreurs et la prise en charge de nombreux protocoles de sĂ©curitĂ©.
GraphQL
GraphQL est une norme API dĂ©veloppĂ©e par Facebook qui permet aux clients de dĂ©crire prĂ©cisĂ©ment la manière dont ils souhaitent rĂ©cupĂ©rer les donnĂ©es. Au lieu que le client envoie plusieurs requĂŞtes pour construire la structure de donnĂ©es requise, GraphQL utilise la technique de requĂŞte pour permettre au demandeur d’exiger une structure de rĂ©ponse JSON exacte que le serveur doit renvoyer. Le principal avantage de GraphQL est sa flexibilitĂ©, qui permet aux clients de construire des requĂŞtes sophistiquĂ©es sans que l’Ă©quipe de dĂ©veloppement du serveur n’ait Ă crĂ©er une API pour chaque structure de rĂ©ponse demandĂ©e.
API et points de terminaison
Il est essentiel de faire la diffĂ©rence entre deux concepts liĂ©s : l’API et le point de terminaison. L’API dĂ©crit les protocoles qui permettent Ă un client de communiquer avec un serveur, tandis que le point de terminaison est l’URL ou tout autre point d’entrĂ©e qui permet Ă l’API de gĂ©rer les communications. Le point de terminaison est l’endroit oĂą l’API accède aux ressources du serveur pour traiter les demandes et les rĂ©ponses.
Par exemple, ClickSend prend en charge diverses API telles que Email to SMS, Countries et Fax. Pour chaque API, il existe plusieurs points de terminaison connexes. L’API Fax comporte des points de terminaison pour l’envoi d’une tĂ©lĂ©copie et pour le calcul du prix total des tĂ©lĂ©copies envoyĂ©es.
Remarque : Bien que vous invoquiez toujours des points d’extrĂ©mitĂ© d’API, vous entendrez les techniciens dire “appeler une API”, ce qui signifie appeler un point d’extrĂ©mitĂ© d’API. Ne vous y trompez pas.
![Diagramme API vs Endpoint montrant une API avec 3 endpoints, avec une requête entrante et une réponse sortante](https://i.imgur.com/1yfkvgv.png?format=webp)
SĂ©curitĂ© de l’API
La sĂ©curitĂ© de l’API est indispensable. Vous pouvez vouloir accorder l’accès Ă un groupe spĂ©cifique d’utilisateurs ou contrĂ´ler le niveau d’accès de chaque utilisateur. Pour ce faire, vous devez tenir compte de la sĂ©curitĂ© dans votre conception. Trois Ă©lĂ©ments principaux doivent ĂŞtre pris en compte lors de la conception d’une API sĂ©curisĂ©e.
Authentification
Vous devez vous assurer que chaque client qui effectue une demande auprès de votre API est autorisé à le faire.
Il existe plusieurs façons d’authentifier les clients d’une API lorsqu’ils l’appellent. L’une d’entre elles consiste Ă gĂ©nĂ©rer une clĂ© unique pour chaque client et Ă lui demander de l’envoyer chaque fois qu’il appelle l’API. Lorsque vous recevez la demande d’un client, vous la vĂ©rifiez par rapport Ă la clĂ© unique gĂ©nĂ©rĂ©e et acceptez ou rejetez l’appel Ă l’API en fonction de la demande de validation. Le principal inconvĂ©nient de cette approche est que l’application serveur sera responsable de la gestion des clĂ©s des clients.
![Diagramme d'authentification de clé API avec le client API envoyant une demande de clé API, le serveur validant la clé et acceptant ou rejetant la demande.](https://i.imgur.com/QGbMLXE.png?format=webp)
Un autre moyen consiste Ă utiliser un serveur de confiance tiers. Votre API “fait confiance” Ă un serveur tiers. En d’autres termes, elle enregistre chaque client d’API attendu dans le serveur de confiance. Le serveur Ă©met un identifiant et un secret client pour que chaque client puisse s’authentifier.
Lorsqu’une application client souhaite appeler le serveur API, elle appelle d’abord le serveur de confiance Ă l’aide de l’identifiant et du secret du client. Si les informations d’identification sont valides, le serveur de confiance gĂ©nère un jeton d’accès limitĂ© dans le temps qu’il peut envoyer au serveur API.
Lorsque le serveur API reçoit le jeton d’accès, il le valide Ă l’aide de la signature numĂ©rique afin de s’assurer qu’il a Ă©tĂ© gĂ©nĂ©rĂ© par le serveur de confiance. Si c’est le cas, le serveur API accepte la demande et renvoie la rĂ©ponse. Dans le cas contraire, il rejette le jeton.
Le principal avantage de cette approche est qu’elle confie la gestion des identifiants Ă un tiers. Les protocoles typiques de cette approche sont OpenID Connect, SAML 2.0 et OAuth 2.0.
![Diagramme d'authentification basé sur le serveur de confiance de l'API avec des jetons de demande et de retour au serveur de confiance](https://i.imgur.com/pscB6IR.png?format=webp)
Autorisation
Après avoir authentifiĂ© vos clients API, vous devez les autoriser pour leur donner l’accès “juste suffisant” dont ils ont besoin, ni plus ni moins.
Supposons, par exemple, que vous construisiez une API permettant aux utilisateurs d’obtenir des informations sur les employĂ©s. Vous voudrez peut-ĂŞtre contrĂ´ler les attributs des employĂ©s que chaque application cliente doit pouvoir voir. Pour l’application de paie, vous voudrez peut-ĂŞtre mettre Ă disposition le salaire de l’employĂ©. Si le client de l’API est un système de voyage, vous voudrez peut-ĂŞtre n’exposer que le nom et le numĂ©ro de passeport.
Comme indiquĂ© prĂ©cĂ©demment, il existe plusieurs mĂ©thodes pour autoriser les clients de l’API, en fonction de la mĂ©thode d’authentification utilisĂ©e. Par exemple, si vous authentifiez les clients Ă l’aide de clĂ©s client, vous pouvez attribuer un niveau d’accès Ă chaque clĂ© API. Lorsque vous recevez l’appel API du client, vous pouvez rĂ©soudre le niveau d’accès correspondant en fonction de la clĂ© API attachĂ©e et contrĂ´ler les donnĂ©es que vous exposez au client Ă partir du code de logique mĂ©tier dans votre backend.
D’autre part, si vous utilisez une approche basĂ©e sur un serveur de confiance pour authentifier vos clients, vous pouvez demander Ă votre serveur de confiance d’attacher un “rĂ´le” au jeton d’authentification que votre serveur gĂ©nère pour le client de l’API. Lorsque le client de l’API vous envoie le jeton d’authentification, l’API de votre serveur l’extrait et l’utilise pour rĂ©soudre l’accès comme dĂ©crit prĂ©cĂ©demment.
Cryptage
Le dernier aspect que vous devrez prendre en compte dans la conception de votre API est le cryptage de la connexion entre le client et le serveur de l’API. Pour ce faire, vous pouvez utiliser des certificats SSL. Le cryptage de la connexion client-serveur garantit que personne entre les deux ne peut Ă©couter la communication et voler les donnĂ©es, ce qui est connu sous le nom d’attaque de l’homme du milieu.
Meilleures pratiques en matière d’API
Si vous utilisez une API, vous devez suivre les meilleures pratiques du secteur pour garantir un produit de haute qualité. Vous trouverez ci-dessous quelques éléments communs à prendre en compte.
SpĂ©cifications de l’API
Étant donnĂ© que votre API prend en charge des formats d’entrĂ©e et de sortie spĂ©cifiques, ainsi que des messages d’erreur, la coordination de ces Ă©lĂ©ments mobiles avec les clients de l’API peut s’avĂ©rer fastidieuse.
Il existe plusieurs normes pour rĂ©soudre ce problème. Il s’agit par exemple de la spĂ©cification OpenAPI pour les API REST et du WSDL pour SOAP. Ces normes sont gĂ©nĂ©ralement crĂ©Ă©es en tant que points d’extrĂ©mitĂ© distincts dans votre API.
Les clients peuvent utiliser ces points de terminaison pour gĂ©nĂ©rer le code cĂ´tĂ© client nĂ©cessaire Ă l’appel de l’API. De cette manière, vous ferez gagner du temps aux dĂ©veloppeurs lorsqu’ils utiliseront votre API.
L’Ă©tranglement
Certaines API peuvent être très sollicitées, ce qui dégrade les performances globales du système.
Pour y remĂ©dier, vous devez utiliser un mĂ©canisme d’Ă©tranglement. DĂ©finissez une limite d’utilisation spĂ©cifique pour votre API, par exemple 200 appels/minute. Lorsque votre système commence Ă recevoir plus de 200 appels/minute, il demande au client de l’API d’attendre avant d’envoyer d’autres demandes. Une mĂ©thode courante consiste Ă utiliser l’erreur HTTP 429 Too Many Requests.
Codes d’erreur, journalisation et surveillance
Comme tout système logiciel, votre API connaîtra des erreurs et des problèmes pour plusieurs raisons, telles que le format de la demande du client, les difficultés de connectivité et les erreurs internes du serveur.
Vous devez renvoyer au client de l’API des codes d’erreur clairs indiquant ce qui s’est passĂ© afin de permettre le dĂ©pannage au niveau du client. Vous devez Ă©galement consigner et surveiller ces erreurs afin que votre Ă©quipe d’exploitation puisse les rĂ©soudre.
Pagination
Si votre API renvoie un objet de rĂ©ponse volumineux, vous devez paginer cette rĂ©ponse pour Ă©viter de surcharger le système. Supposons que vous ayez un point de terminaison d’API qui renvoie la liste de tous les livres d’une bibliothèque. Chaque objet de rĂ©ponse contient des dĂ©tails sur le livre, notamment le titre, l’auteur, l’intrigue et les critiques.
Si vous crĂ©ez un point d’accès Ă l’API pour renvoyer tous les livres en une seule demande, votre objet de rĂ©ponse deviendra si volumineux qu’il provoquera très probablement des dĂ©passements de dĂ©lai et des blocages au niveau du client et une surcharge de la mĂ©moire au niveau du serveur. L’utilisation de la pagination rĂ©sout ce problème.
Au lieu de tout renvoyer dans un seul objet de rĂ©ponse, divisez votre objet de rĂ©ponse en plusieurs “pages”, chaque page ayant une taille limitĂ©e, par exemple 100 livres. Ă€ chaque demande, le client de l’API indiquera la page qu’il souhaite recevoir : la page 1 pour les livres compris entre 1 et 100, la page 2 pour les livres compris entre 101 et 200, et ainsi de suite. De cette manière, vous pouvez fournir des rĂ©ponses petites et efficaces Ă vos clients de l’API.
Mise en cache
Si votre API renvoie une réponse spécifique trop souvent, vous pouvez la mettre en cache. La mise en cache vous permet de stocker des objets accédés de manière répétée dans une technologie de stockage à récupération rapide.
Au lieu d’aller chercher vos donnĂ©es dans le stockage traditionnel, ce qui peut prendre 200 ms, vous pouvez stocker l’objet le plus consultĂ© dans un cache pour le rĂ©cupĂ©rer rapidement chaque fois que vous en avez besoin. Avec un cache, vous obtiendrez un temps de rĂ©ponse plus court, de l’ordre de 20 ms. L’expĂ©rience de l’utilisateur s’en trouve amĂ©liorĂ©e, car les applications se chargent plus rapidement.
Conclusion
Les API peuvent vous aider à révolutionner vos systèmes logiciels. Elles permettent une communication plus universelle et améliorent vos offres aux consommateurs tout en vous aidant à sauvegarder votre propriété intellectuelle.
L’important est de vous assurer que vous gĂ©rez correctement vos API, en particulier les aspects liĂ©s Ă la sĂ©curitĂ©, tout en suivant les meilleures pratiques du secteur pour leur conception et leur utilisation. Ce faisant, vous ferez de vos API un vĂ©ritable atout pour votre entreprise.
Des entreprises tierces fournissent Ă©galement des API pour vous aider Ă amĂ©liorer votre système. Par exemple, ClickSend permet aux entreprises d’avoir des communications internes et externes plus rapides et plus fluides via les SMS, les courriels, les appels vocaux avec synthèse vocale et les canaux de messagerie comme WhatsApp. Pour en savoir plus sur les API proposĂ©es par ClickSend, consultez sa documentation.
A propos de l’auteur
Mohammed Osman 🇸🇪
Twitter : @cognitiveosman
Mohammed Osman est un ingĂ©nieur logiciel senior qui a commencĂ© Ă coder Ă l’âge de treize ans. Ses compĂ©tences de base sont celles d’un Ă©cosystème .NET, avec une forte concentration sur C#, Azure et la science des donnĂ©es. Il aime l’aspect pratique de l’ingĂ©nierie logicielle et dirige des Ă©quipes scrum. Il partage des conseils de codage et de carrière sur son blog.