Comprendre en 5 minutes les API

Une API (Application Programming Interface) est un ensemble normalisé de classes, de méthodes, de fonctions et de constantes qui sert de façade par laquelle un logiciel offre des services à d’autres logiciels, afin d’échanger des données et des fonctionnalités.

Types d’API

Il existe quatre principaux types d’API couramment employés.

Une API publique (ou API externe), est une API ouverte pour tous les développeurs, qui propose l’accès à ses données et ses services sous forme de libre-service. Cela suppose généralement une authentification et une autorisation modérées.

Une API privée (ou API interne), est une API créée et utilisée uniquement au sein de l’entreprise. Ce type d’API n’est pas accessible pour des développeurs externes.

Une API partenaire est une API qui est partagée uniquement à une liste de développeurs ou d’entreprises bien définie. Les droits d’accès à l’API sont de fait plus restrictifs que ceux d’une API publique.

Une API composite est une combinaison de plusieurs API. Cela permet de grouper plusieurs requêtes en un seul appel API. Cette réduction du nombre d’appels améliore la vitesse et les performances de l’API. Ce type d’API est généralement utilisé dans les micro services.

Protocoles et architectures d’API

Il existe plusieurs protocoles et architectures d’API pour permettre cet échange de données et de fonctionnalités. Ils sont régis par des règles, des structures, et des contraintes différentes.

REST

L’architecture REST (Representational State Transfer) est un style d’architecture qui suit plusieurs principes fondamentaux:

Les API REST sont majoritairement utilisées pour les sites web accessibles au public. Elles permettent d’avoir une communication relativement simple entre le client et le serveur.

Ce sont des API flexibles, qui peuvent s’adapter à différents types de données (même si le JSON est le plus répandu).

SOAP

SOAP (Simple Object Access Protocol) est un protocole d’échange d’informations utilisant le XML (Extensible Markup Language).

Ce protocole définit de façon stricte comment les messages doivent être envoyés, et ce qui doit être inclus dedans. Cela fait de SOAP un protocole plus sécurisé que REST, mais qui le rend en contrepartie plus lourd au niveau du code, et plus compliqué à implémenter de façon générale.

SOAP utilise généralement le protocole HTTP, mais contrairement au REST, il n’est pas restreint à celui-ci, et peut utiliser le SMTP par exemple.

Il est généralement utilisé pour les applications liées au paiement, qui demandent une haute sécurité, ou pour des API internes.

RPC

RPC (Remote Procedural Call) est un protocole qui invoque des actions ou des processus exécutables sur un serveur.

Il peut aussi bien utiliser du JSON (avec le protocole JSON-RPC) ainsi que du XML (avec XML-RPC).

Contrairement aux API REST, le RPC n’accepte que les requêtes de type GET ou POST.

Le RPC se démarque par des payloads plus légers, ce qui améliore nettement les performances des requêtes client-serveur.

Dernièrement, c’est le framework gRPC, développé par Google qui s’est démarqué grâce à toutes ses améliorations apportées au protocole RPC. Il utilise HTTP/2 pour le transport des données, Protobuf (Protocol Buffers) comme format de sérialisation, qui encode les données envoyées et reçues pour minimiser le poids des requêtes, et encore améliorer les performances.

GraphQL

GraphQL est un langage de requête créé par Facebook, qui propose une alternative à REST. Il utilise une architecture basée sur un système de schéma de requêtes typé qui permet d’éviter les problèmes d’over/under-fetching, c’est à dire que le client récupère exactement ce qu’il demande au serveur, sans surplus de données inutiles.

Contrairement aux autres protocoles et architectures d’API, c’est le client qui définit les données à récupérer, et non pas le serveur qui décide quelles données à renvoyer.

Cela permet d’améliorer les performances sur les requêtes faites au serveur en s’assurant qu’il n’y aura pas de surplus d’informations, mais également de s’assurer que les données demandées sont bien existantes, et dans le bon type demandé.

Ce langage possède cependant quelques limitations, comme le fait de ne pas pouvoir gérer facilement l’upload & le download de fichiers. Néanmoins, chez TheCodingMachine nous sommes fans et avons développé notre propre librairie PHP pour aller avec GraphQL : GraphQLite.

Si vous souhaitez aller plus loin dans votre compréhension du secteur et du vocabulaire tech, n’hésitez pas à lire notre : livre blanc « Do you speak technique ? »


par tcm
Extrait de « Do You Speak Technique ? »

Articles similaires TAG