Une API c'est quoi ?

L'acronyme API veut dire Application Programming Interface. Le mot important c'est "Interface" : une API permet à un système d'offrir ses services à d'autres systèmes.

C'est un peu comme le menu d'un restaurant : il indique ce qu'il est possible de commander dans ce restaurant et sous quelles conditions.

En tant que Product Manager je trouve qu'il est important de comprendre ce qu'est une API mais aussi de pouvoir juger de la qualité d'une API voire de savoir la tester. Il y a parfois des situations ou il faut choisir un outil selon plusieurs critères notamment économiques, fonctionnels, mais l'API si elle est utilisée doit être évaluée pour éviter des galères dans l'intégration.

Exemples d'API

APIFlash : pour la génération de screenshot

Cette API est très simple. Elle permet d'obtenir la capture d'écran d'une page web à partir d'un simple appel.

Dans sa version la plus basique, l'appel est uniquement de cette forme :

https://api.apiflash.com/v1/urltoimage?access_key=407e4c00570e479db7a742750600&url=https://www.apple.fr

On retrouve 3 éléments presque toujours présents dans une API :

• l'adresse de l'API (ou de la partie de l'API qui nous concerne)
• une façon de s'authentifier
• un ou plusieurs paramètres

Cet appel renverra cette capture d'écran :

On l'utilise sur Blog4ever pour égayer la liste des blogs d'un utilisateur :

Exemple d'utilisation d'une API de screenshots

Sendinblue : pour l'envoi d'email

Envoyer un email cela paraît simple non ?
En réalité, envoyer un email c'est simple mais s'assurer qu'il soit ouvert c'est une vraie galère !

Quand on démarre un site on a la possibilité d'envoyer un email via le même serveur que celui qui héberge notre site mais il est très probable que cet email ne passera pas les antispams des Gmail, Hotmail, etc...

C'est pour cela qu'il existe des services comme Sendinblue, Mailgun, Sendgrid, etc.. Ils s'assurent que les emails sont envoyés de la bonne façon et se chargent de configurer les serveurs d'email.

Pour demander à ce type de prestataire d'envoyer un email, on passe par leur API.

Concrètement ça consiste à appeler une URL avec certains "paramètres".
Voici un exemple d'appel à l'API Sendinblue :

Explications :

• https://api.sendinblue.com/v3/smtp/email => c'est l'adresse de l'API
• api-key : **** : dans presque toute API il y a un moyen de s'authentifier. Dans ce cas là cela permet à Sendinblue ne nous reconnaître et d'utiliser notre quota d'emails (leur pricing se base sur le nombre d'emails envoyés)
• tout ce qui se trouve après "--data" : ce sont les fameux paramètres, en l'occurence le nom de l'expéditeur,  l'email de l'expéditeur, l'email du destinataire et l'id du template (dans cet exemple, un template est déjà créé depuis le site de sendinblue)

Stripe : pour le paiement

Stripe est devenu leader du marché des paiements en proposant une solution de paiement à la fois robuste et facile à mettre pour les développeurs.

Chez Blog4ever on utilisait la solution du CIC qui présentait plein de problèmes et nous obligeait à traiter manuellement beaucoup de cas. Depuis que l'on est chez Stripe, tout est automatique !

L'API de Stripe est reconnue pour être une des mieux documentée. Au delà de lister ce que propose leur API, ils ont carrément des tutoriaux pas à pas pour mettre en place chaque type de paiement.
Voici un exemple de documentation pour un paiement basique : https://stripe.com/docs/payments/checkout/one-time

Des APIs en interne

Une bonne pratique pour construire une application est de séparer la partie "Back" (base de données, traitements) de la partie "Front" (affichage) et de les faire communiquer à travers une API.

On peut même isoler encore plus chaque partie en ayant plusieurs petites applications ayant chacune leur API, comme si elles étaient chacune indépendantes.

Amazon utilise ce type d'architecture. En 2002, Jeff Bezos avait d'ailleurs envoyé cela à tous les employés, avec son ton toujours très aimable :

1) All teams will henceforth expose their data and functionality through service interfaces.
2) Teams must communicate with each other through these interfaces.
3) There will be no other form of interprocess communication allowed: no direct linking, no direct reads of another team’s data store, no shared-memory model, no back-doors whatsoever. The only communication allowed is via service interface calls over the network.
4) It doesn’t matter what technology they use. HTTP, Corba, Pubsub, custom protocols — doesn’t matter.
5) All service interfaces, without exception, must be designed from the ground up to be externalizable. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions.
6) Anyone who doesn’t do this will be fired.

En résumé, chaque service interne doit proposer une interface (API) et doit possiblement être externalisable.

Comment tester une API ?

Le logiciel de référence est Postman.

exemple-postman

La partie en rouge correspond aux infos en entrée : adresse de l'API, paramètres, authentification, ...
La partie en vert c'est le retour de l'API. Dans cet exemple, c'est l'API Pixabay qui renvoie des photos de fleurs jaunes.

La partie encadrée en bleue correspond à la méthode d'appel. Ici c'est GET, souvent utiliser pour lire des informations, mais il y a aussi PUT, POST, DELETE pour ajouter, modifier ou supprimer du contenu. Le type de méthode à utiliser est précisé dans la documentation de l'API.

Et vous, quelles sont les APIs que vous utilisez le plus souvent ? Avez-vous des astuces ou bons liens à partager sur ce sujet ?