Outils pour utilisateurs

Outils du site


stage:turgot:btssn:2020:couderchon.jonathan:api

Une API sûr Proxmox


Proxmox VE utilise une API de type REST. Une API permet à un logiciel de communiquer à un autre logiciel.

Lorsque l'ont programmation une API cela consiste à définir comment un logiciel peut contrôler les fonctionnalités qu'elles exposent ainsi que les interactions possibles (ex: suppression de données, création ou mise à jour) de manière sécurisée aux autres logiciels ou à un utilisateur.

L'utilisation d'une API permet à l'utilisateur de :

  • Tâches d'automatisation : créer un script qui permettra d'exécuter des tâches qui sont manuelles automatiquement.
  • Intégration de données : permets à une application de consommer des données fournies par une autre application ou bien même interagir avec cette autre application, (ex: un site de commerce électronique utilisant des services de paiement accessibles à la banque du client via une API REST)
  • Fonctionnalité : Une application peut intégrer des fonctionnalités de d'autre application dans leurs produit, (ex: Uber échangent des données avec Google Maps ce qui permet de créer et d'optimiser les itinéraires de voyage). Ces sites peuvent également intégrer des fonctionnalités de Google Maps dans leurs propres applications et sites Web pour présenter des cartes d'itinéraires en temps réel.

Les API REST ont trois type de styles architecturaux populaire elle sont SOAP, REST et RPC.

REprésententational State Transfer ou REST est un style architectural rédigé par Roy Thomas Fielding un informaticien américain au chapitre de sa thèse de dorctorat, Architectural Styles and the Design of Networkbased Software Architectures, en 2000.

Roy Thomas Fielding à définit six contraintes appliquées aux élément de l'architecture:

  • client-serveur : permet de programmer un client pour plusieurs plates-formes et simplifier les composants coté serveur.
  • Statique : la demande du client au serveur doivent contenir toutes les informations dont le serveur a besoin pour effectuer la demande. Le serveur ne peut pas contenir d'états de session.
  • Mémoire cache : Les réponses du serveur si la réponse est mise en cache ou non. Si il est possible de mettre en cache, le client peut utiliser les données de la réponse pour les demandes ultérieures.
  • Interface uniforme : Une interface qui doit respecter quatre principes dans la forme des message et de la réponse du serveur.
  • Système en couches : Le système est composé de différentes couches hiérarchiques dans lesquelles chaque couche fournit des services uniquement à la couche au-dessus. Il consomme donc les services de la couche ci-dessous.
  • Code à la demande : Il s'agit de la réponse dû à une requête API.

Lorsque ces six contraintes sont appliquées il s'agit d'un API RESTful


Une API de service Web RESTest une interface de programmation API communiquent via HTTP en respectant les principes du syle architectural REST.

Lorsqu'une API REST communique via HTTP, elle utilise les mêmes concepts que le protocole HTTP :

  • Requêtes/réponses HTTP
  • Verbes HTTP
  • Code d'état HTTP
  • Entêtes/corps HTTP


Les requêtes d'API REST sont composées de quatre composants principaux. Identification de ressources uniformes (URI) ou bien parfois appelé Uniform Ressource Locator (URL), identifie la ressource que le client souhaite manipuler.

Exemple de requête :

Plusieurs méthode HTTP sont diponible:

  • POST : Créer → permet de créez un nouvel objet ou une nouvelle ressource.
  • GET : Lecture → permet de récupérer les détails des ressources à partir du système.
  • PUT : Mettre à jour
  • PATCH : Mise à jour partielle → permet de mettre à jour certains détails à partir d'une ressource exitante
  • DELETE : Supprimer → permet de supprimer une ressource du système.

Les réponses des API REST sont identique au requêtes, mais ils sont composées de trois composants principaux:

  • Etat HTTP : est un code d'état à 3 chiffres (avec comme premier chiffre qui indique la catégorie) cela permet au client de savoir si la requête à réussie ou si elle à échouée.
  • En-tête : est facultatif et utilise le format d'en-tête HTTP standard qui fourni des infromations supplémentaires sous la forme de paire nom-valeur qui est séparés de deux points (:), (ex: [name]:[value].
  • Corps : est facultatif et contient les données des demandées en spécifiant le type de données dans l'en-tête à l'aide de la clé Content-Type. En cas d'échec de la requête de l'API REST a échoué, le corps peut fournir des informations supplémentaires sur le problème ou une action qui doit être prise pour que la demande réussisse.

Catégories des réponse d'API REST :

  • 1xx - Informationnel : Indique que le serveur a reçu la demande mais n'a pas fini le traitement. Le client doit attendre une réponse complète plus tard.
  • 2xx - Succès : Le serveur a reçu et accepte la demande. Lorsque l'API synchrones, les réponses contiennent les données qui sont demandées dans le corps lors d'un échange. Lorsque l'API asynchrones, les réponses ne contiennent généralement pas de corps et le code d'état 2xx et une confirmation de la demande a été reçue mais n'est pas encore satisfaite.
  • 3xx - Redirection : Le client a une action supplémentaire à faire pour que la demande soit complétée. Parfois il faut utilisée une URL différente. Selon la façon dont l'API REST a été invoquée, l'utilisateur peut être automatiquement redirigé sans action manuelle.
  • 4xx - Erreur du client : La requête client contient une erreur (ex: mauvaise syntaxe)
  • 5xx - Erreur du serveur : Le serveur est incapable de répondre à la demande même si la demande est valide. Selon le code d'état 5xx particulier, le client peut vouloir réessayer la demande ultérieurement.

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'information d'identification d'authentification valide 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

Il existe plusieurs logiciels qui permet d'utiliser une API :


Accueil

stage/turgot/btssn/2020/couderchon.jonathan/api.txt · Dernière modification: 2021/05/28 11:11 de couderchon.jonathan_educ-valadon-limoges.fr