> ## Documentation Index > Fetch the complete documentation index at: https://docs.arkatech.fr/llms.txt > Use this file to discover all available pages before exploring further. # Différents type d'APIs > Les APIs sont les contrats qui définissent la manière dont les différents systèmes (services backend, applications frontend, applications tierces) peuvent interagir et échanger des données. Le choix du style d'API est crucial pour la performance, la flexibilité et la sécurité. # REST (Representational State Transfer) REST est un **style architectural** basé sur le protocole HTTP. Il s'appuie sur le concept de **ressources** (URI) et utilise les **méthodes HTTP standards** (GET, POST, PUT, DELETE) pour effectuer des opérations CRUD (Create, Read, Update, Delete) sur ces ressources. **Principes Clés** * **Sans État (Stateless) :** Chaque requête du client au serveur doit contenir toutes les informations nécessaires à la compréhension de la requête. Le serveur n'enregistre aucune information de session spécifique au client entre les requêtes. * **Client-Serveur :** Séparation claire entre l'interface utilisateur (client) et le stockage de données (serveur). * **Mise en Cache (Cacheable) :** Les réponses doivent déclarer si elles sont *cacheables* pour améliorer les performances. * **Interface Uniforme :** Utilisation d'URI pour identifier les ressources et de méthodes HTTP standard pour les actions. **Avantages** * **Standard du Web :** REST est le standard *de facto* pour les API Web publiques, ce qui assure une grande interopérabilité. * **Simplicité :** Facile à comprendre, à mettre en œuvre et à tester grâce aux méthodes HTTP. * **Mise en Cache Naturelle :** Utilise la mise en cache HTTP native pour les requêtes GET. **Inconvénients** * **Sur-Extraction (Over-Fetching) :** Le client reçoit souvent plus de données que nécessaire, car le serveur envoie la représentation complète de la ressource. * **Sous-Extraction (Under-Fetching) :** Le client doit parfois faire plusieurs requêtes successives (par exemple, obtenir une liste de commandes, puis faire une requête pour chaque article dans la commande) pour obtenir toutes les données connexes. * **Granularité Fixe :** La structure des données retournées est fixée par le serveur. **Format Typique** * JSON (le plus courant) ou XML. # GraphQL (Graph Query Language) GraphQL est un **langage de requête de données** pour les APIs. Au lieu de multiples points de terminaison renvoyant des structures de données fixes, GraphQL n'expose qu'un **unique point de terminaison** et permet au client de **définir exactement les données dont il a besoin**. **Principes Clés** * **Schéma Fort (Schema) :** L'API est définie par un schéma de types (Strongly Typed Schema) que le client peut interroger (via une requête `Query`) ou modifier (via une requête `Mutation`). * **Une Seule URL :** Toutes les requêtes sont envoyées à la même URL, généralement via une requête POST. * **Filtre Côté Client :** Le client ne reçoit que les champs explicitement demandés. **Avantages** * **Flexibilité et Efficacité :** Élimine le *Over-Fetching* et le *Under-Fetching*. Le client reçoit uniquement les données exactes nécessaires. * **Réduction des Requêtes :** Permet de récupérer plusieurs ressources connexes en une seule requête au lieu de multiples requêtes REST. * **Développement Front-end Rapide :** Permet au *frontend* d'itérer rapidement sans attendre que le *backend* modifie les structures de réponse. **Inconvénients** * **Complexité de Mise en Cache :** La mise en cache HTTP standard est difficile, car toutes les requêtes sont des POSTs vers la même URL. * **Complexité Serveur :** Le développement du résolveur (*resolver*) côté serveur est plus complexe, car il doit gérer la logique d'extraction de données pour chaque champ possible. * **Sécurité et Limites de Débit :** Plus difficile à sécuriser et à limiter (rate limit) que REST. **Format Typique** * JSON. # gRPC (Google Remote Procedure Call) gRPC est un framework moderne de **haute performance** pour les appels de procédures à distance (RPC). Il est principalement utilisé pour la **communication interne** (Microservices) et s'appuie sur HTTP/2 pour le transport et **Protocol Buffers** pour la sérialisation des données. **Principes Clés** * **HTTP/2 :** Utilise les fonctionnalités d'HTTP/2 comme le multiplexage (plusieurs requêtes sur une seule connexion) et la compression des en-têtes. * **Protocol Buffers (Protobuf) :** Utilise un format de sérialisation binaire efficace (plus rapide et plus petit que JSON), défini via un fichier IDL (Interface Definition Language). * **Streaming :** Supporte nativement le *streaming* bidirectionnel et unidirectionnel. **Avantages** * **Performance Exceptionnelle :** La sérialisation binaire de Protobuf et HTTP/2 rendent gRPC beaucoup plus rapide et efficace en bande passante que REST ou GraphQL. * **Typage Strict :** L'utilisation de Protobuf assure une forte cohérence entre le client et le serveur (typage fort). * **Multi-Langage :** Les fichiers Protobuf peuvent générer le code client et serveur dans pratiquement n'importe quel langage de programmation. **Inconvénients** * **Moins lisible :** Les données binaires sont illisibles par l'humain sans désérialisation, rendant le débogage plus difficile. * **Support Navigateur :** Non nativement supporté par les navigateurs web modernes (nécessite un *proxy* comme gRPC-Web). * **Pas le standard Web :** Principalement utilisé pour la communication de service à service (*service-to-service*). **Format Typique** * Protocol Buffers (Format binaire). # WebSockets WebSockets est un protocole qui permet une **communication bidirectionnelle et persistante** entre un client et un serveur sur une seule connexion TCP longue durée. Il est idéal pour les applications nécessitant un échange de données en **temps réel**. **Principes Clés** * **Handshake (Poignée de main) :** La connexion commence par un *handshake* HTTP standard (passage de `http://` à `ws://` ou `https://` à `wss://`), puis la connexion passe au protocole WebSocket. * **Full-Duplex :** Le serveur et le client peuvent envoyer des données indépendamment à tout moment. * **Faible Latence :** Une fois la connexion établie, il n'y a plus la surcharge des en-têtes HTTP répétitifs. **Avantages** * **Temps Réel :** Permet la diffusion instantanée des données du serveur au client sans que le client ait besoin de *poller* (interroger périodiquement) le serveur. * **Faible Surcharge :** Une fois la connexion établie, la surcharge de transmission est minime. **Inconvénients** * **Complexité de Mise à l'Échelle :** Maintenir des milliers de connexions persistantes sur les serveurs nécessite une architecture de *load balancing* spécifique (stickiness). * **Débogage :** Peut être plus complexe à déboguer que les simples requêtes HTTP. **Cas d'Usage** * Chats en direct, notifications en temps réel, jeux multijoueurs. * Flux de données financiers ou sportifs. # Tableau Comparatif des Styles d'API | **Caractéristique** | **REST** | **GraphQL** | **gRPC** | **WebSockets** | | :------------------ | :--------------------------------- | :--------------------------------------- | :------------------------------------ | :------------------------------------- | | **But Principal** | CRUD sur Ressources | Requête de données flexible | Appels de procédure haute performance | Temps Réel Bidirectionnel | | **Transport** | HTTP/1.1 (ou HTTP/2) | Généralement HTTP/1.1 (POST) | HTTP/2 | Protocole WebSocket (démarré par HTTP) | | **Format Données** | JSON / XML | JSON | Protocol Buffers (Binaire) | N'importe quel format (JSON, binaire) | | **Granularité** | Fixe (par ressource) | Client-définie (par champ) | Fixe (par fonction) | N/A (messages bruts) | | **Cas d'Usage** | API publiques, sites web standards | Mobile, *Front-end* complexe, agrégation | Microservices, IoT, haute performance | Chat, notifications, jeux en direct |