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.
- API publiques :
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.
- API privé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.
- API partenaires :
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.
- API composites :
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:
- Client-Serveur : les responsabilités sont séparées entre le client et le serveur. Le client envoie les requêtes au serveur, et le serveur retourne les réponses au client. Ils doivent être indépendants : un changement sur l’un ne doit pas impacter l’autre.
- Stateless : (Sans état) Chaque interaction client-serveur est indépendante. Le serveur ne stocke pas les données des requêtes précédentes.
- Cache : Les réponses du serveur peuvent être mises en cache, pour améliorer les performances et éviter d’appeler le serveur pour récupérer des données qui n’évoluent pas ou peu.
- Layered : (Système multicouche) Architecture qui permet d’avoir plusieurs serveurs intermédiaires qui peuvent améliorer l’extensibilité du système en mettant en place une répartition de charge et un cache partagé.
- Interface uniforme : Le client et le serveur communiquent avec le protocole HTTP, qui possède plusieurs méthodes de communication (GET, POST, PUT, DELETE, …). Chaque requête possède un URI (Uniform Resource Identifier), et renvoie des données sous une forme prédéfinie (JSON, XML, …).
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 ? »
