Existe-t-il vraiment une différence entre les termes API et REST ?

18 juillet 2019

– 3 min de lecture

Erik Zanga

Manager Architecture

Ces dernières années, lorsque nous parlons d’API, nous revenons, systématiquement, sur les concepts d’interfaces REST, un des paradigmes permettant de mettre en pratique une démarche API.

N’existe-t-il donc que des API REST ? Est-il indispensable, pour mener une politique d’API, de faire référence aux architectures REST ?

La réponse théorique et celle pratique différent, et pour cela nous vous proposons d’analyser les deux points de vue :

La théorie : bien sûr que non

Nous pouvons définir l’API comme un moyen d’échange permettant, par le biais de technologies web, d’exposer des services, apportant une réponse à son utilisateur d’une façon synchrone.

REST, quand à elle, est une architecture logicielle basée sur le HTTP et qui propose de concevoir et d’exposer des services, en exploitant pleinement le potentiel de ce protocole.

Donc nous avons bien le dualisme :

API est l’objectif, le QUOI
REST est le COMMENT, l’architecture logicielle sur laquelle nous pouvons nous appuyer

REST est ainsi un des socles sur lequel nous pouvons définir notre politique API mais qui ne se résume qu’à un moyen. Moyen qui n’est pas forcément exclusif.

La pratique: non mais…

La pratique est différente, pas forcément discordante mais arrondit les dissemblances entre les deux notions.

Le REST est, à ce jour, l’architecture logicielle qui satisfait le mieux les objectifs d’une démarche API, dont le principal est le rapprochement entre besoin client et informations nécessaires à le satisfaire. Nous allons alimenter cette hypothèse en utilisant la notion de DATA et donc élargir la description de l’API en prenant en considération son lien très intime avec la donnée.

Dans l’objectif de marier ce binôme, nous allons analyser, comme contre-exemple, le modèle SOAP. Sans vouloir rentrer dans l’éternel débat de SOAP vs REST, nous allons comparer ces deux concepts, en nous focalisant sur leur interaction avec la donnée.

Une interface SOAP est surtout conçue avec un objectif d’action, de méthode, alors qu’un service REST, si bien architecturé, effectue ses opérations sur une ressource. Le service REST manipule ainsi une entité métier définie. Bien que les deux concepts puissent être considérés comme étant similaires, la réalité est fortement différente. Prenons par exemple la réservation d’un voyage :

En SOAP nous créons une méthode appelée « reserverVoyage ». Ici nous ne savons pas comment va être formalisé, en termes de données, la réservation, nous savons uniquement que nous effectuons une action de réservation
En REST nous allons manipuler la ressource « réservation ». Ici nous modifions, avec un verbe de type PUT, une entité métier « réservation », qui est identifié en termes de données et d’attributs, deux concepts portés par l’API

Le choix de manipuler directement la donnée, au niveau de l’API REST, permet de mener une réflexion complète, qui descend jusqu’à la modélisation de la donnée, modélisation qui devient facilement lisible au niveau des APIs.
Rappelons-nous ! Un système d’information est essentiellement un écosystème qui transforme de la donnée.

Théorie ou pratique ?

Une API doit être conçue en partant de son objectif primaire : manipuler la donnée, en ouvrant sur les possibles actions que l’utilisateur / l’application cliente peut effectuer pour tirer et / ou apporter de la valeur.

C’est là ou le REST et l’API se rejoignent et, à aujourd’hui, se lient dans un objectif commun.

Le REST est à ce jour la solution sur laquelle se base la stratégie API car ce paradigme architectural incarne complètement les concepts d’API, en attendant de voir si le GraphQL tiendra ses promesses…