L'API ou Application Programming Interface présente des fonctions et des règles qui permettent l'interaction et la communication entre différentes applications. Ces interfaces facilitent l'intégration des applications, permettant aux développeurs de créer de puissants produits numériques.

L'API assure la médiation entre les applications via des requêtes et des réponses. Par exemple, l'enregistrement dans l'application via le compte Twitter existant de l'utilisateur se produit via l'API Twitter que les développeurs ont intégrée à l'application. REST API timeline L'API utilise divers protocoles et architectures pour envoyer des requêtes et des réponses :

  1. XML-RPC — permet l'échange de fonctions entre les réseaux. XML-RPC utilise XML pour décrire les réponses/requêtes et les protocoles HTTP pour le transfert d'informations du client au serveur.
  2. JSON-RPC est un RPC léger similaire à XML. Ici, le protocole est encodé en JSON ; il permet de recevoir des appels vers le serveur avec des réponses asynchrones.
  3. SOAP — un protocole d'accès à un objet simple pour échanger des informations structurées lors de la mise en œuvre de services Web dans des réseaux informatiques. SOAP utilise XML pour l'authentification, l'autorisation et la communication de processus sur les systèmes d'exploitation. Il permet aux clients d'appeler des services Web et de recevoir des réponses indépendamment de la plate-forme et de la langue.
  4. API REST (transfert d'état représentatif) - un style architectural utilisant des implémentations client-serveur indépendamment. REST utilise le protocole HTTP pour la communication.

Dans cet article, nous nous concentrons sur l'API REST, la définissons et analysons en quoi elle diffère des autres API.

Définition de l'API REST

REST est un style architectural pour la conception d'API via le protocole HTTP. Son principal avantage est sa grande flexibilité.

Les développeurs utilisent l'API REST partout où il est nécessaire de fournir des données à l'utilisateur d'une application Web ou d'un site directement à partir du serveur. REST API model Les principaux composants de l'API REST :

  • Client — un client ou un programme lancé du côté de l'utilisateur (sur son appareil) initiant la communication.
  • Serveur — un serveur utilisant des API comme accès à ses fonctions et données.
  • Ressource — tout contenu (vidéo, texte, image) que le serveur transmet au client.

Fonctionnement de l'API REST REST API methods

L'API REST communique via des requêtes HTTP, remplissant les fonctions suivantes - création, lecture, mise à jour et suppression de données. Elles sont également connues sous le nom d'opérations CRUD. REST fournit les informations sur les ressources demandées et utilise quatre méthodes pour décrire ce qu'il faut faire avec une ressource :

POST — création d'une ressource ;

GET — obtenir une ressource ;

PUT — mise à jour d'une ressource ;

DELETE — suppression d'une ressource.

Ressource

Une ressource est un concept critique dans l'API REST, une abstraction d'informations. Il peut s'agir de n'importe quelle information : document, image, service temporaire.

L'état de la ressource à un moment donné est connu sous le nom de représentation de la ressource qui se compose de données, de métadonnées décrivant les données et de liens hypermédias pour aider les clients à passer à l'état suivant.

Les informations peuvent être livrées au client dans différents formats : JSON, HTML, XLT, Python ou texte brut. Le plus populaire et le plus utilisé est JSON car il est lisible par l'homme et la machine, et indépendant du langage.

Pour accéder à une ressource, un client doit faire une demande. Après l'avoir reçu, le serveur générera une réponse avec des données codées sur une ressource.

La structure de la requête comprend quatre composants principaux : la méthode HTTP (CRUD mentionnée précédemment), les points de terminaison, les en-têtes et le corps.

La méthode HTTP décrit ce qui doit être fait avec la ressource. Juste au-dessus, nous avons mentionné quatre méthodes disponibles : POST, GET, PUT, DELETE.

Le point de terminaison contient un URI — Uniform Resource Identifier, qui indique comment et où la ressource peut être trouvée. Une URL ou Uniform Resource Location est le type d'URI le plus courant, représentant une adresse Web complète.

Les en-têtes contiennent les données relatives au client et au serveur. Les en-têtes incluent les données d'authentification : clé API, nom, adresse IP qui appartiennent à l'ordinateur sur lequel le serveur est installé, ainsi que les informations sur le format de réponse.

Le corps est utilisé pour envoyer des informations supplémentaires au serveur, telles que les données que vous souhaitez ajouter.

Principes de l'API REST

REST n'est lié à aucune technologie ou plate-forme particulière. Il est indépendant de la langue. Il ne précise pas non plus précisément comment créer l'API. Mais il utilise six contraintes architecturales. L'interface peut être appelée une API REST valide en suivant ces contraintes. Ils décrivent comment le serveur traite les requêtes et y répond.

Serveur client

L'API REST implémente un style d'architecture client-serveur. Le client envoie des demandes de ressources et n'est pas associé au stockage de données. Le stockage des données reste à l'intérieur du serveur. Les serveurs ne sont pas impliqués dans la communication avec l'interface utilisateur. Le client et le serveur évoluent de manière interdépendante. Ce facteur rend le REST encore plus flexible et évolutif.

Interface uniforme

L'interface unifiée est un facteur essentiel qui distingue l'API REST. Il indique qu'il existe un seul moyen de communiquer avec le serveur, sans impliquer le type d'application et de périphérique.

L'interface uniforme repose sur quatre principes :

  • Identification des ressources. Chaque ressource doit avoir une identification indépendante de l'état des ressources. L'URL agit comme un identifiant.
  • Manipulation des ressources par les représentations. Une représentation de ressource (que possède le client) contient les données requises pour supprimer ou modifier la ressource. Le client envoie une représentation que le serveur (un objet JSON) doit modifier, supprimer ou ajouter.
  • Messages auto-descriptifs. Ces messages contiennent toutes les informations nécessaires au destinataire pour sa compréhension. Aucune information supplémentaire n'est requise dans une documentation ou des messages distincts. Chaque message contient suffisamment d'informations pour que le serveur analyse la demande.
  • L'hypermédia comme moteur d'état de l'application. Hypermédia nécessite l'utilisation de liens pour chaque réponse afin que le client puisse trouver d'autres ressources. Dans REST, l'hypermédia est utilisé pour toutes les interactions.

Apatride

Cela signifie que le serveur ne contient aucune donnée sur le client. Toutes les informations nécessaires au traitement de la demande sont incluses dans la demande. Le client stocke toutes les informations de session.

Cacheable

Chaque réponse doit contenir des informations indiquant si elle peut être mise en cache ou non et la période pendant laquelle la réponse peut être mise en cache. S'il peut être mis en cache, alors dans des requêtes similaires, le client peut utiliser les mêmes données sans envoyer de manière répétée des requêtes au serveur. Cela permet d'améliorer les performances et la disponibilité.

Système en couches

REST implémente la hiérarchie des couches, ce qui crée certaines restrictions sur le comportement des composants. Dans un système en couches, les composants ne peuvent voir que les composants situés aux niveaux les plus proches et ceux avec lesquels ils interagissent.

Code à la demande

Il s'agit d'une fonctionnalité facultative permettant aux clients de télécharger et d'exécuter du code.

Qu'est-ce qui différencie l'API REST ?

Les six principes de l'API REST peuvent être considérés comme les principales différences entre cette interface et les autres types. De plus, plusieurs paramètres distinguent REST.

Premièrement, l'essence même de REST détermine son incompatibilité avec d'autres types. Il s'agit d'un style architectural où une architecture représente un ensemble d'exigences que vous devez suivre pour fournir un service Web RESTful. Par exemple, SOAP et RPC sont des protocoles de messagerie qui décrivent des messages. Contrairement au style architectural, qui ne spécifie que les exigences (contraintes) auxquelles le message doit répondre.

Structure

Habituellement, l'API suit le format d'application à application, tandis que REST suit une structure différente - Client-Serveur. Le client et le serveur évoluent indépendamment, offrant plus de souplesse dans le travail.

Format d'échange de messages

Les API utilisent généralement des formats de message spécifiques ; par exemple, SOAP utilise XML. REST ne suit pas un principe aussi strict. Il peut utiliser presque n'importe quel format pour échanger des données. Cependant, JSON est maintenant le plus populaire.

Il y a des raisons évidentes derrière la popularité du JSON - il est lisible par l'homme et facile à analyser le format d'échange de données. JSON est indépendant du langage et vous pouvez l'utiliser avec n'importe quel langage en plus de JavaScript.

La flexibilité

REST est un style architectural flexible, les développeurs l'utilisent donc largement. Comparé à SOAP - un protocole plus complexe avec des fonctionnalités de sécurité avancées nécessitant plus de bande passante, REST consiste en des directives simples qui permettent aux développeurs d'utiliser ces exigences dans leur format. L'architecture offre des performances élevées, ce qui la rend particulièrement demandée pour les appareils mobiles, où la vitesse de téléchargement est importante.

Comme nous le voyons, REST présente certains avantages par rapport aux autres API connues. C'est pourquoi toutes les grandes entreprises telles que Twitter et Google l'ont implémenté pour leurs produits. Après tout, c'est le moyen idéal et facile de transférer des données aux développeurs du monde entier et un mécanisme éprouvé pour créer des interfaces efficaces et évolutives pour le développement de logiciels.