Ceci est une ancienne révision du document !
Une API permet à un logiciel de communiquer à un autre.
La programmation d'une API va consister à définir comment un logiciel peut contrôler les fonctionnalités qu'elles exposent et les interactions possibles ( création, mise à jour ou suppression de données) de manière sécurisée aux autres logiciels ou à un utilisateur.
Voici quelques-uns cas d'utilisation pour les API:
Les API sont généralement conçues pour être synchrones lorsque les données de la requête sont facilement disponibles, par exemple lorsque les données sont stockées dans une base de données ou dans une mémoire interne. Le serveur peut immédiatement récupérer ces données et répondre immédiatement.
L'application cliente qui effectue la demande d'API doit attendre la réponse avant d'effectuer des tâches supplémentaires d'exécution de code.
Avantages : l'application reçoit les données immédiatement. Inconvénient : si l'API n'est pas correctement conçue, elle sera un goulot d'étranglement car l'application doit attendre la réponse.
Si la requête d'API prend un certain temps de traitement pour le serveur ou si les données ne sont pas facilement disponibles, il est préférable d'utiliser des API asynchrones.
L'application cliente doit alors être en mesure d'être informer ou de s'informer lorsque le résultat de sa requête API est disponible.
Avantages : l'application client peut de poursuivre l'exécution sans être bloquée pendant le temps nécessaire au serveur pour traiter la demande. L'application client peut avoir de meilleures performances car elle peut être multitâche et faire d'autres requêtes. Inconvénient : l'utilisation inutile ou excessive d'appels asynchrones peut avoir l'effet inverse sur les performances.
Les trois types les plus populaires de styles architecturaux API sont RPC, SOAP et REST.
REST ou REprésententational State Transfer (REST) est un style architectural rédigé par l'informaticien américain Roy Thomas Fielding au chapitre 5 de sa thèse de doctorat, Architectural Styles and the Design of Networkbased Software Architectures, en 2000.
Roy Thomas Fielding définit six contraintes appliquées aux éléments de l'architecture:
Quand ces six contraintes sont appliquées il s'agit d'une API RESTful.
Une API de service Web REST (REST API) est une interface de programmation (API) qui communique via HTTP tout en respectant les principes du style architectural REST.
Comme une API REST communique via HTTP, elle utilise les mêmes concepts que le protocole HTTP :
Les requêtes d'API REST sont composées de quatre composants principaux:
Les méthodes HTTP :
Méthode | HTTP | Action | Description |
---|---|---|---|
POST | Créer | Créez un nouvel objet ou une nouvelle ressource. | |
GET | Lecture | Récupérez les détails des ressources à partir du système. | |
PUT | Mettre à jour | ||
PATCH | Mise à jour partielle | Mettez à jour certains détails à partir d'une ressource existante. | |
DEL | Supprimer | une ressource du système. |
Exemple d'en-tête de requête fournissant le jeton d'accès d'identification :
Clé | Exemple de valeur | Description |
---|---|---|
Autorisation | dmFncmFudDp2YWdyYW50 | Fournir des informations d'identification pour autoriser la demande |
Les en-têtes d'entité sont des informations supplémentaires qui décrivent le contenu du corps du message.
Exemple d'en-tête d'entité précisant le format des données souhaité :
Clé | Exemple de valeur | Description |
---|---|---|
Type de contenu | application/json | Spécifier le format des données dans le corps |
Les réponses API REST sont similaires aux requêtes, mais sont composées de trois composants principaux:
Les cinq catégories de réponse d'API REST :
Les codes d'état HTTP communs :
Code d'état HTTP | Messages d'état | Description |
---|---|---|
200 | OK | La requête a réussi et contient généralement une charge utile (corps) |
201 | Créé | La demande a été exécutée et la ressource demandée a été créée |
202 | Accepté | La demande a été acceptée pour traitement et est en cours |
400 | Demande incorrecte | La demande ne sera pas traitée en raison d'une erreur avec la demande |
401 | Non autorisé | La requête n'a pas d'informations d'identification d'authentification valides pour effectuer la demande |
403 | Interdit | La demande a été comprise mais a été rejetée par le serveur |
404 | Introuvable | Impossible d'exécuter la demande car le chemin de ressource de la demande n'a pas été trouvé sur le serveur |
500 | Erreur interne du serveur | La demande ne peut pas être traitée en raison d'une erreur de serveur |
503 | Service non disponible | La demande ne peut pas être traitée car actuellement le serveur ne peut pas gérer la demande |
L'interaction avec un service d'API REST particulier consiste en une séquence de demandes. Pour cette raison, les diagrammes de séquence sont fréquemment utilisés pour expliquer la requête/réponse de l'API REST et l'activité asynchrone.