Une application cliente (comme une application mobile, un navigateur Web ou un autre serveur) envoie une requête à l'API pour effectuer une action. Cette requête est envoyée à une URL spécifique et inclut une méthode HTTP, des en-têtes avec des métadonnées et, parfois, un corps de requête avec des données.

Le serveur reçoit et valide la requête, en confirmant que le client est authentifié et autorisé à effectuer l'action demandée. Il traite ensuite la requête, ce qui peut impliquer de récupérer des données à partir d'une base de données, de créer une ressource ou de mettre à jour une ressource existante.

Après avoir traité la requête, le serveur renvoie une réponse au client. Cette réponse inclut un code d'état HTTP indiquant le résultat (par exemple, 200 OK en cas de réussite, 404 Not Found si la ressource n'existe pas, 401 Non autorisé en cas de problème de sécurité), ainsi que les données demandées dans le corps de la réponse.

Les données transférées entre le client et le serveur sont une "représentation" de l'état de la ressource. JSON (JavaScript Object Notation) est le format le plus courant pour ces données, car il est léger, lisible par l'humain et facile à analyser pour les langages de programmation.

La puissance et l'évolutivité de REST proviennent d'un ensemble de contraintes architecturales qui guident sa conception. Un système qui respecte ces contraintes est considéré comme "RESTful".

Une ressource est un concept fondamental de REST. Il s'agit d'un objet avec un type, des données associées, des relations avec d'autres ressources et un ensemble de méthodes qui s'appliquent à cet objet. Par exemple, dans une API d'e-commerce, un "produit" ou un "client" serait une ressource.

Chaque ressource est identifiée de manière unique par un URI. Une API bien conçue utilise des URI clairs, descriptifs et cohérents pour identifier ses ressources. Par exemple, /users peut identifier un ensemble d'utilisateurs, et /users/123 un utilisateur spécifique avec l'ID 123.

Un client n'interagit pas directement avec la ressource, mais avec une représentation de cette ressource. Le format de représentation le plus courant est JSON, mais d'autres formats comme XML ou HTML peuvent également être utilisés. Cela permet de représenter l'état d'une ressource de manière flexible.

Chaque requête envoyée par un client au serveur doit contenir toutes les informations dont le serveur a besoin pour comprendre et traiter la requête. Le serveur ne stocke aucun contexte client ni aucun état de session entre les requêtes. Cette contrainte rend les API REST hautement évolutives, car n'importe quel serveur peut traiter n'importe quelle requête.

Le client et le serveur sont séparés, et l'API sert d'interface entre eux. Cette séparation des tâches permet à l'application côté client et à l'application côté serveur d'évoluer indépendamment.

REST nécessite une interface cohérente et uniforme entre le client et le serveur. Pour ce faire, REST utilise des méthodes HTTP standards, des URI pour identifier les ressources et l'hypermédia comme moteur de l'état de l'application (HATEOAS).

Les réponses du serveur doivent être définies comme pouvant ou ne pouvant pas être mises en cache. Lorsqu'une réponse peut être mise en cache, un client ou un intermédiaire peut réutiliser cette réponse pour les requêtes identiques suivantes, ce qui peut améliorer considérablement les performances et réduire la charge du serveur.

Un client connecté à une API REST ne peut généralement pas savoir s'il est connecté directement au serveur final ou à un intermédiaire. Des serveurs intermédiaires, comme des passerelles API ou des équilibreurs de charge, peuvent être introduits dans l'architecture pour améliorer l'évolutivité, la sécurité et les performances.

Un cas d'utilisation courant est celui d'une application météo mobile qui récupère les prévisions météorologiques actuelles pour un emplacement spécifique à partir d'une API météo publique.

L'application cliente envoie une requête HTTP GET au point de terminaison de l'API, en incluant l'emplacement et une clé API pour l'authentification.

Le serveur traite la requête, récupère les données météorologiques pour l'emplacement spécifié et renvoie une réponse JSON.

Dans une architecture de microservices, un service "produit" peut avoir besoin d'obtenir un prix mis à jour auprès d'un service "inventaire" avant de l'afficher sur un site d'e-commerce. 

Le service "produit" envoie une requête HTTP GET interne au point de terminaison de l'API du service "inventaire" pour un ID de produit spécifique.

Le service d'inventaire recherche le prix actuel et renvoie une réponse JSON simple.