API REST : API « Application Program Interface »

API REST : En tant qu’ingénieurs réseau, nous utilisons généralement l’interface en ligne de commande, la CLI, ou bien, une interface graphique pour configurer ou surveiller nos périphériques réseau.

L’analyse de sortie des commandes « show » et « debug » par des scripts est assez difficile, car ces commandes sont plutôt destinées aux humains.

C’est pourquoi, dans le but d’interagir avec des applications ou des périphériques réseau, nous pouvons utiliser une interface de programmation d’application, qu’on appelle une API.

Alors même si l’acronyme fait peur, une API c’est simplement une interface logicielle qui permet à d’autres applications de communiquer avec sa propre application.

D’ailleurs, « API » signifie « Application Programming Interface », et le mot le plus important à retenir est « Interface ».

C’est le mot le plus simple, car nous utilisons tous des interfaces au quotidien.

Exemple

Par exemple, la télécommande d’une télévision est une interface.
Car c’est un moyen d’interagir avec la télé, sans avoir besoin de plonger les doigts dans les fils et circuit de sa télé.

Sur la télécommande, il y a un ensemble de boutons qui permettent d’effectuer différentes opérations, comme modifier le volume, changer de chaîne, ou même éteindre la télé avec le bouton rouge.

Chaque bouton correspond à une action précise.

Par exemple, on sait qu’on ne peut pas allumer la télé, avec le bouton de volume.

Pour que ça marche, il faut respecter l’interface et interagir avec elle, de la façon qui a été prévue lors de sa conception.

Sans nous en rendre compte, nous utilisons au quotidien beaucoup d’interfaces.

Un autre exemple est le menu d’un restaurant.

La carte, c’est un peu le moyen d’interagir avec la cuisine.

Différents choix nous sont proposés dans le menu et il faut sélectionner une option.

Le serveur ira communiquer votre choix dans la cuisine, et vous recevrez votre plat en fonction de votre requête.

Eh bien, les sites web et applications ont besoin de la même chose pour communiquer et s’échanger des données.

D’ailleurs c’est là que vient le « AP » de « API ».

Une API est une interface pour les applications, car un logiciel n’a pas de mains ni d’yeux pour interagir avec les interfaces physiques !

Il existe plusieurs types d’API, avec un ensemble différent de conventions selon différents besoins.

Les types d’API

Le CCNA, porte sur le modèle d’API REST (API – REpresentational State Transfer).

API REST

C’est l’API le plus populaire pour les applications d’automatisation de réseau.

Elle a été créée en 2000 par Roy Fielding qui est un informaticien américain ayant beaucoup contribué à l’informatique, car il a participé au développement de plusieurs technologies importantes comme l’HTML (HyperText Markup Language), HTTP (HyperText Transfer Protocol) et URI (Uniform Resource Identifier).
C’est vraiment un spécialiste du Web qui a même cofondé « Apache ».

Elle possède un haut niveau de certification, c’est pourquoi on peut aussi le retrouver avec | les acronymes de « API RESTful ».

Nous allons donc examiner de plus près les API basées sur REST.

Dans la signification d’une API REST (API – REpresentational State Transfer), le mot « representation » signifie que nous transférons la représentation d’une ressource entre un serveur et un client.

Cela se fait généralement sous le format de données JSON (JavaScript Object Notation) ou XML (Extensible Markup Language).

Et le « transfert d’état » signifie que chaque opération avec une API REST est autonome.

Les API REST utilisent fréquemment des méthodes HTTP (HyperText Transfer Protocol) pour récupérer ou envoyer des informations entre les applications.

Ce sont les mêmes méthodes HTTP, que nous utilisons avec un navigateur Web pour visiter un site Web, sauf qu’ici, c’est plutôt utilisé pour interagir avec une application.

Les 4 méthodes les plus populaires de HTTP

On va détailler les 4 méthodes les plus populaires de HTTP :

• Le « GET » : est une méthode, en lecture seule, qui permet de récupérer une ressource spécifiée.
• Le « POST » : permets de soumettre les données à la ressource pour les traiter. Il est aussi capable de créer de nouvelles ressources.
• Le PUT : est la méthode capable de mettre à jour la ressource, en remplaçant les données existantes.
• Et le « DELETE » : permets de supprimer une ressource.

Alors, vous vous demandez peut-être ce qu’est une ressource ?

Eh bien une ressource WEB, est un contenu que l’on trouve en ligne et que l’on peut regarder, lire, écouter, ou même interagir, comme c’est le cas avec les vidéos ou les questionnaires en ligne.

Avec une API REST, il pourrait s’agir d’une ligne, dans une base de données.

Le protocole HTTP étant très populaire, il est donc possible d’utiliser les API REST dans presque tous les langages de programmation.

L’accès à une ressource se fait à l’aide d’une URL (Uniform Resource Locator).

Ce sont les mêmes que nous utilisons pour le WEB.

Dans l’exemple, l’URL est utilisée pour accéder à la ressource de la Loopback 0 sur le routeur 1.

En fait, les « API REST » imitent simplement la façon dont le web fonctionne dans les échanges entre un client et un serveur.

Elle possède six attributs qui sont :

• Architecture client / serveur
• Sans état (Stateless operation)
• Avec une mise en Cache (Cacheable = avec cache = mémoire)
• Avec une interface uniforme
• Avec un système de couche
• Et un code sur demande (optionnel)

Les trois premiers de ces attributs sont au cœur du fonctionnement d’une API REST.

Nous allons donc détailler ces 3 premiers attributs :

Architecture client / serveur

Dans une Architecture « Client-serveur », le client et le serveur sont indépendants.

C’est-à-dire qu’ils interagissent les uns avec les autres grâce aux demandes que le client lance.

Le client envoie une requête, et le serveur qui écoute renvoie une réponse.

Sans État

Dans une configuration sans état, le serveur ne stocke aucun état concernant les demandes qu’il a déjà reçues.

Par exemple, il ne sait pas si un client a déjà demandé une ressource juste avant.

Et il ne permet pas non plus de savoir quelles ressources ont été demandées par un client.

Le fait d’être “sans état” signifie que le serveur n’a aucune idée de l’état du client entre deux requêtes.

Ce qui permet de gagner en performance.

Cacheable

Et avec l’attribut du « cache », le serveur inclut un numéro de version dans ses messages.

Le client peut donc l’utiliser pour décider s’il doit à nouveau demander une ressource ou utiliser les données mises en cache.

C’est le même principe qu’internet :

Le client doit être capable de garder en mémoire des informations sans avoir constamment besoin de demander tout au serveur.

Une bonne gestion des délais de mise en cache améliore.

Dans le paysage technologique actuel, les interfaces de programmation applicatives (API) basées sur le transfert d'état représentationnel se dressent comme des piliers incontournables pour l'intégration et l'automatisation des systèmes numériques.

Elles incarnent une solution élégante pour les développeurs cherchant à construire des applications interconnectées et évolutives, marquant ainsi l'avènement d'une nouvelle ère en matière de connectivité numérique.

Utilisant les protocoles HTTP universels, ces interfaces facilitent l'échange sécurisé et efficace de données, permettant une communication transparente entre diverses applications, indépendamment de leurs complexités sous-jacentes.

Cette compatibilité étendue assure leur pertinence continue, même face à l'évolution rapide de la technologie. Leur adoption généralisée illustre l'importance vitale qu'elles jouent dans la création d'une infrastructure logicielle intégrée, propulsant l'innovation et la coopération dans un monde numérique de plus en plus interconnecté. En résumé, ces interfaces de programmation ne sont pas seulement des outils de connectivité ; elles sont le cœur battant de l'écosystème numérique moderne, essentielles pour façonner l'avenir de la technologie.

N’oubliez pas de vous abonner à la chaîne YouTube Formip.