Un'applicazione client (come un'app mobile, un browser web o un altro server) avvia una richiesta all'API per eseguire un'azione. Questa richiesta viene inviata a un URL specifico e include un metodo HTTP, intestazioni con metadati e, a volte, un corpo della richiesta con dati.

Il server riceve e convalida la richiesta, confermando che il client è autenticato e autorizzato a eseguire l'azione richiesta. Quindi elabora la richiesta, che potrebbe comportare il recupero di dati da un database, la creazione di una nuova risorsa o l'aggiornamento di una esistente.

Dopo aver elaborato la richiesta, il server invia una risposta al client. Questa risposta include un codice di stato HTTP che indica il risultato (ad esempio, 200 OK per esito positivo, 404 Not Found se la risorsa non esiste, 401 Unauthorized per problemi di sicurezza), insieme ai dati richiesti nel corpo della risposta.

I dati trasferiti tra client e server sono una "rappresentazione" dello stato della risorsa. JSON (JavaScript Object Notation) è il formato più comune per questi dati perché è leggero, leggibile e facile da analizzare per i linguaggi di programmazione.

La potenza e la scalabilità di REST derivano da una serie di vincoli architetturali che ne guidano la progettazione. Un sistema che rispetta questi vincoli è considerato "RESTful".

Una risorsa è un concetto fondamentale in REST. È un oggetto con un tipo, dati associati, relazioni con altre risorse e un insieme di metodi che operano su di esso. Ad esempio, in un'API di e-commerce, un "prodotto" o un "cliente" sarebbero una risorsa.

Ogni risorsa è identificata in modo univoco da un URI. Un'API ben progettata utilizza URI puliti, descrittivi e coerenti per identificare le proprie risorse. Ad esempio, /users potrebbe identificare una raccolta di utenti e /users/123 identificherebbe un utente specifico con l'ID 123.

Un client non interagisce direttamente con la risorsa, ma con una rappresentazione di quella risorsa. Il formato di rappresentazione più comune è JSON, ma possono essere utilizzati anche altri formati come XML o HTML. Questo fornisce un modo flessibile per rappresentare lo stato di una risorsa.

Ogni richiesta da un client al server deve contenere tutte le informazioni necessarie al server per comprendere ed elaborare la richiesta. Il server non archivia alcun contesto client o stato della sessione tra le richieste. Questo vincolo rende le API REST altamente scalabili perché qualsiasi server può gestire qualsiasi richiesta.

Il client e il server sono separati e l'API funge da interfaccia tra loro. Questa separazione delle responsabilità consente all'applicazione lato client e all'applicazione lato server di evolversi in modo indipendente.

REST richiede un'interfaccia coerente e uniforme tra client e server. Ciò si ottiene mediante l'uso di metodi HTTP standard, URI per l'identificazione delle risorse e hypermedia as the engine of application state (HATEOAS).

Le risposte del server devono essere definite come memorizzabili nella cache o non memorizzabili nella cache. Quando una risposta è memorizzabile nella cache, un client o un intermediario può riutilizzarla per richieste identiche successive, il che può migliorare significativamente le prestazioni e ridurre il carico del server.

Un client connesso a un'API REST di solito non è in grado di stabilire se è connesso direttamente al server finale o a un intermediario lungo il percorso. È possibile introdurre server intermedi, come gateway API o bilanciatori del carico, nell'architettura per migliorare la scalabilità, la sicurezza e le prestazioni.

Un caso d'uso comune è un'app meteo mobile che recupera le condizioni meteorologiche attuali per una posizione specifica da un'API meteo pubblica.

L'applicazione client effettua una richiesta HTTP GET all'endpoint API, includendo la località e una chiave API per l'autenticazione.

Il server elabora la richiesta, recupera i dati meteorologici per la località specificata e restituisce una risposta JSON.

In un'architettura di microservizi, un servizio "prodotto" potrebbe dover ottenere un prezzo aggiornato da un servizio "inventario" prima di visualizzarlo su un sito di e-commerce. 

Il servizio prodotto effettua una richiesta HTTP GET interna all'endpoint API del servizio inventario per un ID prodotto specifico.

Il servizio di inventario cerca il prezzo corrente e restituisce una semplice risposta JSON.