REST (Representational state transfer) est une manière de construire une application pour les systèmes distribués comme le World Wide Web. Le terme a été inventé par Roy Fielding.

REST n'est pas un protocole ou un format, c'est un style d'architecture, c'est le style architectural original du Web, bâti sur quelques principes simples :

• l'URI est important : connaître l'URI doit suffire pour accéder à la ressource ;
• HTTP fournit toutes les opérations nécessaires (GET, POST, PUT et DELETE, essentiellement) ;
• chaque opération est auto-suffisante : il n'y a pas d'état ;
• utilisation des standards hypermedia : HTML ou XML qui permettent de faire des liens vers d'autres ressources et d'assurer ainsi la navigation dans l'application REST.

Ce style architectural n'est pas limité à la réalisation d'application pour un utilisateur humain. Elle est de plus en plus utilisée pour la réalisation d'architectures orientées services utilisant des services Web destinés à la communication entre machines. REST dans ce cas là se pose en alternative au style architectural RPC et à la plupart des cas d'utilisation de SOAP (bien que l'on puisse imaginer des architectures orientées services de style REST mais utilisant la technologie SOAP), alternative censée être plus simple à mettre en œuvre. Les systèmes qui suivent les principes REST de Fielding sont souvent appelés RESTful. Même si les réponses aux requêtes sont, comme pour SOAP et XML-RPC, souvent en XML, cela n'a rien d'obligatoire. Des réponses JSON ou en objets Java sérialisés sont parfaitement acceptables (il devient de plus en plus conseillé de n'utiliser XML que pour des documents).

La thèse de Roy Fielding précise les avantages de ce style architectural par rapport à d'autres styles d'architectures d'applications web. Citons entres autres :

• L'application est plus simple à entretenir, car les liens sont mieux structurés, et de façon universelle.
• L'absence d'état sur le serveur conduit à une consommation de mémoire inférieure et donc à une capacité plus grande de répondre à un grand nombre de requêtes simultanées.
• L'absence d'état sur le serveur rend le fonctionnement plus simple à appréhender. Le résultat d'une requête ne dépend pas de variables cachées difficilement identifiables. Cela conduit à une mise au point plus simple.
• L'absence d'état sur le serveur permet une répartition des requêtes sur plusieurs serveurs avec une meilleure granularité et de manière plus souple. Cela permet aussi une meilleure tolérance aux pannes d'un des serveurs.
• Le respect de la philosophie du protocole HTTP (à la différence de la manière dont est habituellement utilisé SOAP) conduit à une architecture plus cohérente et plus simple.
• l'utilisation d'URI comme représentant d'une ressource, permet la mise en place de serveurs cache.

Les principaux désavantages de REST sont la nécessité pour le client de conserver localement toutes les données nécessaires au bon déroulement d'une requête, ce qui induit une consommation en bande passante réseau plus grande, et le manque à gagner des capacités du serveur. S'il est possible de coupler une application web REST à un service extérieur assurant la permanence des données lors de la durée d'une session, par exemple une base de données ou un cookie, on pourrait cependant considérer que l'utilisation d'un tel service pour gérer des données relatives à une session ouverte par le client serait en violation de la philosophie de REST. REST préfèrera l'utilisation de tableaux codés en Javascript présents dans la mémoire du navigateur client.

Par ailleurs beaucoup d'applications, bien que ne respectant pas scrupuleusement toutes les contraintes de l'architecture REST sont largement inspirées par elle.