Introduction à REST

Présentation de REST

REST a été créé en 2000 par Roy T. Fieldling, également créateur du projet Apache HTTP Server et membre de la fondation Apache.

Il s’agit d’une architecture permettant à un client d’échanger avec un serveur de manière unitaire, très structurée et gérant le cache. Ainsi, il est possible de mettre en place des couches qui évoluent de manières autonomes.

Classiquement, dans le cas d’un contexte web (WWW - World Wide Web), tel qu’abordé dans ce livre, il s’agit d’une interface web pour le client, et d’une application de gestion de données pour le serveur, qui communiquent ensemble.

REST est indépendant du format représentant les données, que ce soit JSON, XML, ou une autre forme de sérialisation.

Une programmation stateless ou stateful ?

REST est-elle une architecture stateless (sans état) ou stateful (avec état) ?

La réponse est « stateless ». Il n’y a pas de notion de session (au sens large du terme) : le serveur ne se souvient pas des enchaînements des requêtes, ne fait pas varier les réponses selon un enchaînement particulier et ne stocke pas d’informations autres que les actions demandées sur les ressources (création, modification, suppression...).

REST vs RESTful

Vous trouverez au fil de vos lectures des mentions à des applications exposant leurs services en REST, et à d’autres applications exposant leurs services de manière RESTful.

Si une application est sans état, utilise uniquement des méthodes HTTP, expose sa structure dans les URI et qu’elle utilise dans ses requêtes du XML et/ou du JSON, elle respecte les différents préceptes de REST ; elle est donc RESTful.

En résumé, une application qui ne s’expose qu’en REST est RESTful. Si elle s’expose autrement, alors elle n’est pas RESTful.

Formats de sortie et leurs types MIME

Si, à l’origine, MIME (Multi-purpose Internet Mail Extensions) était un standard pour lister les types des données ajoutées à des e-mails, l’usage s’est élargi à toute forme de communication numérique, dont le protocole HTTP.

Les spécifications des types MIME sont actuellement décrites dans les RFC 4288 et 4289, et la liste des types MIME enregistrés est disponible sur le site de IANA (Internet Assigned Numbers Authority).

Un type MIME est composé de deux parties, le type et le sous-type, séparées par un /.

text/html 
text/csv 
application/json 
application/xml 
image/jpeg
 

Certains types permettent l’ajout d’informations complémentaires après le sous-titre. Cette information est optionnelle.

Ainsi, le type text peut être complété de l’encodage des caractères à l’aide de la variable charset.

text/html; charset=iso-8859-1
 

Format des URL, URL logiques et physiques

Lorsqu’une application web statique est créée, il est possible de la parcourir en suivant la structure de ses répertoires.

Ainsi, par défaut, si l’URL suivante est appelée, alors abc est un répertoire et def est un fichier d’extension ghi. Il s’agit d’une URL physique.

http://domaine/abc/def.ghi
 

Avec l’apparition des procédures d’URL rewriting (réécriture d’URL), que ce soit au travers de règles Apache, ou de par la structure dynamique de l’application, ce type d’URL se fait moins présent sur Internet. Les applications masquent la structure physique au profit de chaînes humainement compréhensibles, mieux référencées, et moins sensibles aux attaques. Ce sont des URL logiques.

Par exemple, dans le cas suivant : http://domaine/monArticleSurLaMusique remplace alors http://domaine/monBlog/lire.do?id=1234

L’identifiant de base de données est masqué (id=1234), la technologie Java est masquée (.do) et le nom de l’article (monArticleSurLaMusique) est directement référencé par les moteurs de recherche.