REST API

C’est l’acronyme de REpresentational State Transfer.

C’est un style d’architecture logicielle inspiré de l’architecture du Web (protocole HTTP) défini dans la these de Roy FIELDING en 2000.

Ce n’est ni un format, ni un protocole, ni un standard ;seurlement un ensemble de conventions et bonnes pratiques pour construire une API.

Ressource: L’information
Un objet, un document, une image, un service, une collection, une personne,…
Représentation: L’état de la ressource

Séparation Client-Serveur
Découplage de l’interface utilisateur du stockage des données.
Sans état (Stateless)
Pas de conservation de contexte entre deux requetes successives. Autrement dit, aucune variable de session ou autre état volatile coté serveur.
Cachable (Cacheable)
Les reponses peuvent etre mises en cache permettant ainsi de reduire certaines interactions.
Interface uniformes
Les requetes sont identiques quelques soient les clients.
Pour chaque ressource: un identifiant unique, une representation et auto-descriptive/découvrable.
Architecture multi-couches
Le client ne doit pas savoir ce qui se passe pour obtenir une réponse.
Code à la demande (optionnel)
Les réponses peuvent comporter du code éxecutable.

Chaque ressource est accessible via un identifiant appelé URI (Uniform Ressource Identifier)

Bonnes pratiques pour la définition des URIs

Utilisés dans les requetes HTTP: “GET/somme?a=3&b=2 HTTP/1.1 “

Chaque methode porte une sémantique :

Utilisés dans les réponses HTTP: “HTTP/1.1 200 OK “

Chaque code porte une sémantique:

Au choix : XML, JSON, YAML, HTML, CSV, …

Peut différer entre la requete et la réponse

Se précise dans les entetes HTTP

Content-Type pour préciser le format du contenu (corps) de la requete/ réponse
Accept pour préciser les formats gérés/souhaités en réponse par le client (facultatif)

Attention à l’alternative par préfixe qui modifie ;’URL et donc qui n’est pas RESTful