Cos'è un'API REST vs SOAP vs GraphQL

Quando due sistemi devono scambiarsi dati, lo fanno attraverso un'API. Ma esistono stili diversi per costruirla: REST, SOAP e GraphQL sono i tre più diffusi, e la scelta tra loro influenza come il tuo software comunicherà per anni.

In questo articolo ti spiego le differenze tra REST, SOAP e GraphQL, con i pro e i contro di ciascuno, per aiutarti a scegliere quello giusto.

Un ripasso veloce: cos'è un'API

Un'API è un'interfaccia che permette a due programmi di comunicare scambiandosi dati e comandi. Se vuoi un'introduzione completa, parto dalle basi nell'articolo cos'è un'API. REST, SOAP e GraphQL sono tre modi diversi di progettare quell'interfaccia.

REST: lo standard de facto

REST (Representational State Transfer) è oggi l'approccio più usato sul web. Si basa sui metodi HTTP (GET, POST, PUT, DELETE) e organizza i dati in "risorse" identificate da URL.

GET    /utenti/42      → ottieni l'utente 42
POST   /utenti         → crea un nuovo utente
DELETE /utenti/42      → elimina l'utente 42

• Pro: semplice, leggibile, usa HTTP nativamente, enorme ecosistema, facile da cachare.
• Contro: può richiedere molte chiamate per dati correlati (over/under-fetching), nessun contratto rigido di default.

Approfondisco questo stile nell'articolo dedicato cos'è una REST API.

SOAP: il veterano enterprise

SOAP (Simple Object Access Protocol) è un protocollo più vecchio e formale, basato su XML. Definisce un contratto rigido (tramite WSDL) e include funzionalità avanzate per sicurezza e transazioni.

• Pro: standard molto rigoroso, sicurezza e affidabilità di livello enterprise, indipendente dal trasporto (non solo HTTP).
• Contro: verboso (XML pesante), più complesso da implementare, ormai poco usato fuori da contesti bancari, assicurativi o legacy.

Oggi difficilmente sceglieresti SOAP per un progetto nuovo, ma lo incontri ancora in sistemi aziendali consolidati.

GraphQL: il cliente decide cosa ricevere

GraphQL è un linguaggio di query per API creato da Facebook. Invece di tanti endpoint, ne espone uno solo: è il client a specificare esattamente quali dati vuole.

{
  utente(id: 42) {
    nome
    email
    ordini { totale }
  }
}

• Pro: niente over/under-fetching (ricevi solo ciò che chiedi), un solo endpoint, ottimo per app con dati complessi e correlati.
• Contro: caching più difficile, curva di apprendimento più ripida, può complicare il backend.

Ne parlo più a fondo in cos'è GraphQL.

Tabella di confronto

Aspetto	REST	SOAP	GraphQL
Formato dati	JSON (di solito)	XML	JSON
Struttura	Più endpoint/risorse	Operazioni via WSDL	Un endpoint, query flessibili
Curva di apprendimento	Bassa	Alta	Media
Caching	Facile	Difficile	Difficile
Caso d'uso tipico	Web/mobile moderni	Sistemi enterprise/legacy	App con dati complessi

Come scegliere

• Scegli REST per la maggior parte dei progetti web e mobile: è semplice, supportato ovunque e più che sufficiente.
• Scegli GraphQL quando hai dati molto correlati, client diversi con esigenze diverse, o vuoi ridurre il numero di chiamate.
• Usa SOAP solo se devi integrarti con sistemi enterprise/legacy che lo richiedono.

Non esiste "il migliore" in assoluto: esiste quello giusto per il tuo caso. Capire questa differenza è parte del ragionare da backend developer.

In sintesi

REST, SOAP e GraphQL sono tre stili di API. REST è lo standard semplice e diffuso, ideale per la maggior parte dei progetti. SOAP è il veterano formale degli ambienti enterprise. GraphQL dà al client il controllo totale sui dati richiesti, perfetto per scenari complessi. La scelta dipende dalle esigenze del progetto, non dalla moda.

Vuoi imparare a progettare e consumare API nel modo giusto, con esempi pratici? Lo trovi nei corsi di CodeGrind.