Le terme API REST est souvent croisé, sans que l'on soit nécessairement certaine de sa signification. Il est souvent opposé au principe d'"API RPC", ou simmplement de RPC. Qu'est-ce que cela signifie ?

RPC ?

RPC signifie Remote Procedure Call. Wikipédia le définit comme : "En informatique distribuée, un RPC signifie qu'un ordinateur provoque l'exécution d'une sous-routine (comprendre : une fonction, au sens programmation du terme) située dans un espace d'adressage différent du sien (un autre ordinateur sur le réseau par exemple, mais pas forcément) comme si il s'agissait d'une procédure locale; cela sans que quelqu'un n'ait programmé les détails de cette interaction à distance. L'idée est que, peu importe que la sous-routine soit locale ou distante."

RPC est donc une forme de communication inter-processus. Le client fait un appel, attend que le serveur exécute la requête et renvoie la réponse; par conséquent, il n'as pas de nouvelles de l'avancement de sa requête et une coupure de réseau au mauvais moment est problématique. RPC date des années 60; de nos jours, il est surtout réservé à des systèmes bas niveau soigneusement programmés.

REST ?

REST signifie "REpresentationnal State Transfer". Il s'agit d'un style d'architecture réseau; qui décrit des contraintes à appliquer à une API, lesquelles contraintes doivent être suivies pour être "RESTful":

Découplage client-serveur : Les responsabilités sont séparées entre le client et le serveur. L'UI n'est pas couplée au stockage des données par le serveur (elle n'en dépend pas). Ainsi L'UI est portable et chaque composant peut être mis à jour indépendamment.
Sans état : La communication client-serveur se fait sans conservation d'état entre 2 requêtes. L'état de la session est conservé par le client et retransmis à chaque requête : le client reçoit à chaque fois toutes les informations dont le serveur a besoin. Une exception est faite pour l'authentification.
Mise en cache : Clients comme serveurs peuvent mettre en cache des informations. Les réponse doivent donc se définir d'une façon ou d'une autre comme pouvant être mises en cache ou pas.
En couches : Un client ne peut pas habituellement dire s'il est connecté au serveur final ou non. On peut utiliser des serveurs intermédiaires.
Interface uniforme : Définie selon 4 contraintes (pfiou) : chaque ressource est identifiée dans les requêtes comme avec une URI par ex.; chaque représentation d'une ressource fournit assez d'informations au client pour qu'il puisse la manipuler; les messages sont auto-descriptifs; le client doit pouvoir utiliser des hyperliens une fois son accès à l'URI initial.

En bref, quand on parle d'API REST, on parle en général d'une API s'appuyant sur HTTP et envoyant de l'Hypertexte. Ce style a été inventé en 1995, aux débuts d'internet. Une des idées les plus importantes est qu'une API REST n'as pas besoin de documentation (puisque l'on a une "interface uniforme" : le HTML que je reçoit n'as pas besoin d'être documenté, c'est du html et n'importe quel navigateur peut l'afficher). Hors on évoque souvent ce terme pour parler d'API envoyant du JSON par HTTP, une erreur selon Roy Fielding, créateur du concept REST:

I am getting frustrated by the number of people calling any HTTP-based interface a REST API. Today’s example is the SocialSite REST API. That is RPC. It screams RPC. There is so much coupling on display that it should be given an X rating.
What needs to be done to make the REST architectural style clear on the notion that hypertext is a constraint? In other words, if the engine of application state (and hence the API) is not being driven by hypertext, then it cannot be RESTful and cannot be a REST API. Period. Is there some broken manual somewhere that needs to be fixed?

RPC / REST

RPC ?

REST ?

Menu de navigation