Les interfaces de programmation d’applications (Application Programming Interfaces ou API) permettent aux programmes ou services informatiques de communiquer entre eux. Cette communication se fait généralement par l’intermédiaire d’un point de terminaison de l’API, exposé par un programme qu’un client utilise.

Cet article compare deux approches populaires de la création d’API : l’API REST (Representational State Transfer) et l’API web.

Qu’est-ce qu’une API REST ?

Contrairement à la croyance populaire, l’API REST n’est pas un protocole. Il s’agit d’une architecture, et c’est l’architecture la plus populaire pour le développement d’API. Comme nous l’expliquons dans GraphQL vs REST : Tout ce que vous devez savoir, REST est sans état, c’est-à-dire qu’aucune donnée ou état n’est stocké entre les requêtes.

REST définit également plusieurs contraintes architecturales pour la création d’applications qui communiquent via HTTP :

  • Architecture client-serveur
  • Absence d’état
  • Interface uniforme
  • Possibilité de mise en cache
  • Architecture du système en couches
  • Code à la demande

REST est plus facile à utiliser que d’autres protocoles ou architectures d’API. Il offre également de nombreux autres avantages qui en font le premier choix pour de nombreux développeurs qui créent des API :

  • Divers formats de messages : Les API REST sont principalement utilisées avec JSON pour sérialiser les données, mais elles fonctionnent avec plusieurs formats de message, notamment JSON, HTTP, texte brut et XML. Cet éventail d’options leur confère un avantage par rapport à des protocoles tels que le protocole SOAP (Service Object Access Protocol) qui fonctionne principalement avec XML via HTTP, les options telles que JSON étant nettement plus légères, plus flexibles avec la prise en charge des tableaux et plus faciles à analyser par rapport à XML.
  • Méthodes HTTP : REST est généralement utilisé avec l’une des méthodes GET, POST, PATCH, DELETE, ou PUT pour la récupération de données et la formulation de requêtes, en fonction de l’implémentation du service. Ces méthodes renvoient les codes de réussite et d’échec HTTP habituels. D’autres méthodes sont OPTIONS, HEAD, et TRACE. Ces méthodes ne sont pas cohérentes entre les services, car certains fournisseurs peuvent ne mettre en œuvre qu’une seule méthode en fonction de leurs besoins.
  • Architecture découplée : REST a une architecture client-serveur, de sorte que sa logique est séparée de la présentation – plusieurs parties peuvent être travaillées simultanément sans interférence.
  • Évolutivité : Les API REST sont simples, ce qui les rend faciles à utiliser. Toutefois, si vous avez besoin de passer à l’échelle supérieure, vous pouvez créer de nouveaux points de terminaison pour intégrer une logique plus complexe.
  • Possibilité de mise en cache : Bien que REST soit sans état, la réponse du serveur sur le client peut être mise en cache pour éviter de répéter des demandes redondantes. La réponse du serveur donne généralement des informations sur la manière dont la mise en cache doit être exécutée – le client mettant en cache les demandes pendant une période donnée.
  • Sécurité : Dans la plupart des cas, les points de terminaison REST sont exposés via des points de terminaison HTTPS, ce qui garantit que toutes les communications de l’API sont sécurisées à l’aide de TLS/SSL. REST prend également en charge d’autres systèmes d’autorisation et d’authentification, tels que OAuth2 et JSON Web Tokens (JWT).

Qu’est-ce qu’une API web ?

Une API web est simplement une interface permettant d’accéder aux ressources d’un serveur via HTTP. Le terme fait référence au concept plutôt qu’à une technologie spécifique – une API Web peut être construite avec différentes technologies, comme Java et ASP.NET. Les API Web utilisent une interface à code open source et tirent parti de nombreuses entités clientes telles que les navigateurs, les smartphones, les tablettes et les ordinateurs portables.

Les API web mettent en œuvre des spécifications de protocole avec des concepts tels que la mise en cache, la gestion des versions et divers formats de contenu. Une API web peut être ou non une API REST, selon la manière dont elle est construite. Les API web sont généralement utilisées sur un système distribué pour fournir des services sur différents appareils, tels que les smartphones et les ordinateurs portables, et sont limitées au côté client de l’application web.

Voici deux exemples d’API web largement utilisées :

  • Les API de Google: Il s’agit des API YouTube, qui permettent aux développeurs d’intégrer des vidéos YouTube dans leurs applications telles que des sites web, et de l’API Google Maps, qui permet aux développeurs d’utiliser ou d’intégrer Google Maps sur des pages web à l’aide d’interfaces JavaScript ou Flash.
  • API Twitter : Il s’agit de l’API de recherche Twitter, qui fournit des méthodes pour interagir avec la recherche Twitter, et de l’API REST, qui vous permet d’accéder aux données de base de Twitter.

Une API web est réalisée en tant qu’interaction système à système. Voici comment les données d’une telle API peuvent circuler :

  1. L’appareil client envoie des requêtes au serveur web.
  2. Le serveur web reçoit la requête, la traite, puis la renvoie au dispositif client pour qu’elle soit exécutée.
  3. Le résultat est présenté à l’utilisateur.

Les API web présentent les avantages suivants

  • Architecture légère : Les API web excellent dans les appareils à bande passante limitée, tels que les smartphones.
  • En-têtes de message descriptifs : Les API web ont des en-têtes de message descriptifs, qui peuvent contenir des informations sur le type de contenu, le schéma de sécurité ou la manière de gérer la mise en cache.
  • Prise en charge de tous les types de données : Le corps d’une API web peut être utilisé pour n’importe quoi, y compris des fichiers binaires (vidéos, images, documents), du XML simple, du JSON et du HTML.
  • Service orienté ressources : Une API web peut exposer des ressources d’une manière conforme à l’architecture REST.
  • Facilité de configuration et d’installation : Les API web sont faciles à configurer et à exécuter.

API Web vs API REST

Comparons maintenant ces deux API plus en détail.

Similitudes architecturales

Les API Web et REST présentent certaines similitudes architecturales.

  • Absence d’état : Les requêtes HTTP sont isolées et fondamentalement sans état, car chaque requête contient suffisamment d’informations pour être traitée. Les requêtes multiples ne sont associées les unes aux autres que par le biais d’informations partagées, telles que des cookies ou un identifiant de session. L’absence de synchronisation d’état réduit la complexité et augmente les performances car le serveur n’a pas besoin de suivre les requêtes des clients. Les demandes simultanées peuvent également être réparties sur plusieurs serveurs.
  • Architecture en couches : Ces deux types d’architecture prennent en charge une conception en couches dans laquelle le déploiement de l’API, l’authentification des demandes et le stockage peuvent se faire sur plusieurs serveurs.
  • Orientée vers les ressources : Dans les architectures orientées ressources, les ressources sont mises en correspondance avec des identifiants de ressources uniformes (URI). Les API Web et REST sont toutes deux orientées ressources, car elles exposent les ressources via des URI.
  • Possibilité de mise en cache : Dans les API REST et web, les requêtes qui renvoient les mêmes informations à chaque fois qu’elles sont appelées sont mises en cache. Par exemple, un appel OPTION sur un point de terminaison sera mis en cache car le résultat est le même, quel que soit le nombre d’appels. Cette propriété, connue sous le nom d’idempotence, est une bonne base pour déterminer quand les données peuvent être mises en cache. L’idempotence est toujours prise en compte dans REST, mais pas autant dans les API web. Un appel API idempotent est un appel dont les résultats ne changeront jamais, quel que soit le nombre d’appels, même s’il est possible que quelque chose change sur le serveur. Les méthodes GET, HEAD et OPTIONS sont des exemples de méthodes idempotentes.

Différences d’architecture

Si les API web et les API REST présentent des schémas architecturaux similaires, elles présentent également quelques différences essentielles.

  • Coordination côté client et côté serveur : Les API REST ont une architecture faiblement couplée, ce qui permet un développement indépendant du côté du client et du serveur. Avec les API web, les changements entre le client et le serveur sont plus finement coordonnés.
  • Interface : En fonction des détails de mise en œuvre, les API REST ont tendance à utiliser des interfaces standard. Les API web utilisent des interfaces personnalisées, en fonction du fournisseur d’API.

Communication

Les API web sont suffisamment flexibles pour tirer parti de n’importe quel style de communication, tandis que les API REST sont principalement utilisées avec JSON, XML et le texte brut. Ces options signifient que les API REST fonctionnent bien pour la transmission de données textuelles, telles que les opérations de création, de lecture, de mise à jour et de suppression (CRUD) d’une base de données, mais sont plus restrictives lorsqu’il s’agit de données binaires.

Les API web offrent une bien meilleure expérience pour les services nécessitant des données binaires – comme les services de diffusion dee mùusique ou de vidéo en continu – car elles prennent en charge davantage de formats de messages.

Cas d’utilisation

Bien que ces formats d’API soient interchangeables dans de nombreux cas, il existe quelques scénarios dans lesquels l’un est préférable à l’autre :

  • Services et applications cloud : En raison de leur nature sans état, les API REST sont utilisées dans les services cloud, car les composants sans état peuvent évoluer et être redéployés pour s’adapter aux changements. Les services et les mesures en nuage sont généralement mieux exposés sous forme d’API REST, car il n’est pas nécessaire d’utiliser du code personnalisé.
  • Services de streaming : Les API web offrent une meilleure prise en charge et une faible surcharge de l’application de données binaires sur des appareils à mémoire ou à bande passante restreinte, et sont donc les mieux adaptées aux services qui nécessitent une diffusion en continu.
  • Manipulation de bases de données (CRUD) : Il est plus simple et plus facile d’exposer une fonctionnalité CRUD via une API REST que via une API web.

Les API REST sont difficiles à gérer pour les demandes complexes qui doivent accéder à des ressources qui ne sont pas organisées selon une hiérarchie simple. Cela est dû au fait que les URI font référence à des ressources, ce qui signifie que la gestion de ce type de situation implique la manipulation des chemins URI, des paramètres de requête et du corps de la requête, ce qui va à l’encontre de l’objectif de REST. Dans ce cas, il est préférable d’utiliser une API web, car elle permet la personnalisation et offre une prise en charge étendue de la réponse URI et des en-têtes de requête.

Grâce à la prise en charge de techniques telles que les appels asynchrones – qui ne sont pas faciles à mettre en œuvre à l’aide de l’architecture REST – les API web sont la solution idéale pour les besoins complexes en matière d’API.

En bref

Les API web et REST sont utilisées pour créer des applications qui fournissent des ressources et communiquent via HTTP. Alors que REST décrit les contraintes architecturales d’une interface uniforme, les API web sont généralement un concept qui peut être RESTful, en fonction de la mise en œuvre.

Les API web et REST sont des formats légers qui sont interchangeables dans de nombreuses situations. Toutefois, par rapport aux API REST, les API web offrent une expérience plus personnalisée et la prise en charge d’un plus grand nombre de types de messages, ainsi que des interactions complexes entre les serveurs et les clients traitant des données binaires.

Grâce aux services d’hébergement d’applications de Kinsta, vous pouvez créer, tester et expédier vos projets d’API dans le cloud plus rapidement et plus efficacement.

Salman Ravoof

Salman Ravoof is a self-taught web developer, writer, creator, and a huge admirer of Free and Open Source Software (FOSS). Besides tech, he's excited by science, philosophy, photography, arts, cats, and food. Learn more about him on his website, and connect with Salman on Twitter.