C'est quoi une API ?

Cet article est le 4ème de la mini-série "Comment fonctionne une application web".

Tu n'as pas lu les premiers articles ?

• Comment on communique sur le web
• C'est quoi le frontend
• La différence entre le frontend et le backend

Si tu n'es pas à l'aise avec les concepts, je te conseille de lire les épisodes dans l'ordre 😊.

Et sinon,

let's gooooo ! 💥

Once again, l'exemple du restaurant:

Je reprends l'exemple du restaurant "A cucina". On avait vu que dans ce restaurant il y a Sébastien au service et la cheffe Laura.  Mais tu n'as pas accès directement à la cuisine:

• Tu ne sais pas ce que tu peux commander puisque tu ne connais pas les stocks d'ingrédients disponibles.
• Tu ne peux pas directement passer commande

Il te faut donc :

• Un menu avec la liste des plats que tu peux commander
• Sébastien qui peut prendre ta commande, la valider et t'emmener le plat

L'API c'est l'interface qui va permettre à Sébastien de communiquer avec la cuisine.

Pour être utilisée, une API est nécessairement fournie avec une documentation, en gros c'est le mode d'emploi de l'API.

Une API s'utilise donc en deux étapes:

1. Lire la documentation pour comprendre comment utiliser l'API
2. Utiliser l'API

Cette documentation d'API :

• Présente la liste des plats disponibles
• Précise comment chaque plat peut être commandé ( par exemple pour un steak, il faut impérativement préciser la cuisson parmi une liste d'option ).

Tu peux donc maintenant préparer ta commande ( ce qu'on appelle la requête ). Une fois la commande préparée, tu peux passer commande, c'est à dire envoyer ta requête à l'API.

A ce moment, l'API va:

• recevoir ta commande ( l'API est une interface de communication qui peut recevoir des requêtes )
• valider ou non ta requête ( par exemple si tu commandes un steak avec une cuisson "tomate" l'API va te renvoyer une erreur, car "tomate" ne fait pas partie des options de cuisson.
• une fois ta requête validée, l'API va transmettre ta commande à la cuisine qui va réaliser ton plat
• et enfin, l'API va répondre à ta requête en te disant "OK c'est parti!" ou alors "erreur, nous n'avons plus de steak".

L'API est nécessaire pour utiliser le backend

Le backend, c'est comme la cuisine, on ne peut pas y accéder et l'utiliser directement. Il faut donc que le backend ait une interface pour pouvoir être utilisé.

Une API c'est l'interface qui permet d'utiliser une application ( Application Programming Interface ).

Une API n'est pas une interface humain - machine. On ne peut pas directement utiliser une API, c'est une interface machine - machine. C'est à dire qu'une API ne peut être utilisée que par d'autres applications.

On dit alors que l'API serveur est consommée par des clients.

Allez c'est parti, on va créer une API !

Disons qu'on crée une programme qui permet de vérifier si une adresse postale existe.

C'est ce dont le backend est capable.

On peut tous les deux utiliser ce programme directement sur notre ordinateur, mais on veut que le monde entier puisse l'utiliser.

On va donc créer une API pour pouvoir utiliser ce programme.

Notre API ne sait faire qu'une seule chose, il n'y a qu'une seule fonctionnalité, donc notre API aura un seul "endpoint".

Un "endpoint" c'est l'URL sur lequel on peut envoyer notre requête, et en gros il y a un endpoint par fonctionnalité.

On va appeler ce endpoint: api/adress/verify

Pour utiliser notre programme, on doit envoyer notre adresse à vérifier sur le endpoint, dans un format bien précis sinon l'API refusera la requête. Si tu te rappelles les premiers articles, on va ici faire une requête POST 😉

Tu peux donc envoyer:

{
    number: "1",
    adress: "rue Victor-Hugo",
    city: "Marseille"
}

L'API va recevoir ta requête, vérifier si tout est valide et envoyer ta demande au backend pour vérifier si cette adresse existe. Le backend mouline, trouve que cette adresse existe et te réponds donc:

{
	exists: true
}

Si l'adresse n'existe pas, l'API te répond:

{
	exists: false
}

Trop bien, notre backend est maintenant doté d'une API !

Le frontend utilise l'API

Cette API peut évidemment être utilisée par un frontend, et oui, le frontend permet de communiquer directement avec une API !

Si on se rappelle, le frontend c'est une interface humain - machine. En tant qu'humains on peut utiliser le frontend directement, et le frontend peut lui directement utiliser l'API !

On peut donc faire une page web avec un formulaire dans lequel on tape l'adresse, et ça nous affiche si l'adresse existe ou pas.

C'est bien, mais honnêtement, qui va utiliser ce frontend ?

* grand silence *

Une API peut être consommée par d'autres applications

L'intérêt des API c'est qu'elles peuvent être utilisées par d'autres applications que le frontend.

Sur le plan business c'est pas DU TOUT à négliger. Vos users payants peuvent ne jamais être des humains mais d'autres applications techs ( des Saas, e-commerce whatever... ).

Dans notre exemple on va clairement jamais vendre cette application à des humains.

En revanche, cette API peut être vendue comme un service Saas à des milliers de boîtes de logistique et de e-commerce !

Et oui, ces entreprises vont pouvoir automatiquement vérifier si l'adresse de leurs clients existe avant de leur envoyer les colis. Fini les colis perdus et les coûts liés.

On imagine très bien que veepee.com, à chaque fois que vous passez commande aille vérifier si l'adresse existe, et si elle n'existe pas n'envoie pas le colis et annule la commande, automatiquement.

Et c'est ça le potentiel des API : permettre des intégrations entre différents backend et pouvoir proposer des services beaucoup plus intelligents et beaucoup plus connectés.

Article suivant:

C’est quoi le backend ?

Le backend, c’est là où est réalisé la logique d’un système informatique. On appelle ça une application serveur. Si on reprend la métaphore du restaurant, c’est la cuisine: * Il y a un stock d’ingrédients ( des objets ) * Il y a des fiches recettes ( des données ) * Il y a un robot qui

Decode - by TancrèdeTancrède Simonin