GraphQL o REST: come scegliere l'API giusta nel 2026

Scegli REST quando i dati sono semplici, i client si comportano in modo simile e vuoi gli strumenti più diffusi. Scegli GraphQL quando molti client diversi hanno bisogno di porzioni diverse degli stessi dati, oppure quando una sola schermata attinge da più fonti. Per la maggior parte dei prodotti in fase iniziale REST è la scelta migliore. E quando un prodotto supera i limiti di REST, di solito è per la varietà dei client, non per il traffico.

Il resto dell'articolo spiega da dove nasce questa regola, cosa dicono le misurazioni e quanto costa ogni scelta nel lavoro quotidiano. Sviluppiamo applicazioni web e piattaforme a Zurigo, quindi affrontiamo anche il lato pratico: cosa chiederti prima di decidere.

In breve

• REST è uno stile architetturale costruito attorno a risorse e URL. GraphQL è un linguaggio di interrogazione con uno schema tipizzato, servito di solito da un unico endpoint.
• GraphQL elimina over-fetching e under-fetching ed è adatto a client eterogenei e a più fonti di dati. REST è più semplice, si mette in cache più facilmente ed è adatto ad applicazioni piccole.
• In uno studio accademico GraphQL ha mostrato tempi di risposta medi più bassi sulla maggior parte degli endpoint, ma REST ha scalato meglio con elevata concorrenza.
• GraphQL sposta il lavoro sul server: limiti al costo delle query, problema N+1 e caching richiedono tutti una progettazione consapevole.
• Per un primo prodotto con un unico client web, parti da REST. Passa a GraphQL quando la varietà dei client fa moltiplicare gli endpoint.

Cosa sono davvero, l'uno e l'altro

I due non sono cose dello stesso tipo, ed è per questo che i confronti diventano confusi. REST è un modello architetturale. GraphQL è un linguaggio di interrogazione e un runtime. Un'API REST espone risorse su URL come /orders/42, e il metodo HTTP indica cosa farci. Un'API GraphQL espone uno schema, e il client invia una query che descrive la forma esatta dei dati che vuole ricevere.

Hanno più cose in comune di quanto facciano pensare i dibattiti. Secondo la AWS AppSync documentation, entrambi seguono un modello client-server, entrambi sono stateless ed entrambi di norma viaggiano su HTTP. Puoi costruire un'API scadente in entrambi gli stili, e una buona API in entrambi gli stili.

Una sintesi utile: con REST è il server a decidere cosa restituisce ogni endpoint. Con GraphQL è il client a decidere cosa gli serve, nei limiti di ciò che lo schema consente.

Confronto diretto

Criterio	REST	GraphQL
Idea di fondo	Risorse dietro molti URL	Uno schema, di solito un unico endpoint
Forma dei dati	Fissata dal server per ogni endpoint	Scelta dal client per ogni query
Over-fetching e under-fetching	Frequenti	Evitati per costruzione
Schema	Facoltativo (per esempio OpenAPI)	Obbligatorio, fortemente tipizzato
Caching HTTP	Immediato	Più difficile, richiede lavoro extra
Tempo reale	Long-polling o server-sent events	Subscription
Curva di apprendimento	Bassa	Media
Contesto ideale	Dati semplici, client simili tra loro, API pubbliche	Molti client, molte fonti di dati, dati annidati

Le righe nascono dagli stessi compromessi che le prossime sezioni spiegano uno per uno.

Recupero dei dati: over-fetching, under-fetching e viaggi di andata e ritorno

È il motivo per cui GraphQL esiste. Immagina una schermata ordini su mobile che deve mostrare il nome del cliente, gli ultimi tre ordini e lo stato di ciascuno. Con REST faresti una chiamata a /customers/7, poi a /customers/7/orders, poi una chiamata di stato per ogni ordine. Questo è under-fetching: la prima risposta non basta, quindi fai altre richieste. Nel frattempo ogni risposta porta con sé campi che la schermata non mostra mai, e questo è over-fetching.

Uno University of Washington study on GraphQL and REST performance descrive esattamente questo: REST può portare a entrambi i problemi, mentre GraphQL permette ai client di specificare cosa recuperare e può riunire dati da più fonti in un'unica richiesta. La documentazione di AWS dice la stessa cosa in termini pratici: GraphQL riduce il carico di rete restituendo solo i dati richiesti in una sola chiamata.

Esiste anche una risposta in chiave REST. Puoi aggiungere endpoint dedicati a ogni schermata, oppure accettare parametri che selezionano i campi. Funziona, ma così ogni nuovo client aggiunge lavoro sul server. È il punto in cui i team iniziano a considerare GraphQL: non quando REST è lento, ma quando il numero di varianti degli endpoint sfugge di mano.

Prestazioni: cosa dicono le misurazioni

Diffida di qualsiasi articolo che sostenga che uno dei due è semplicemente più veloce. I ricercatori della University of Washington hanno misurato entrambi gli stili in diversi scenari di carico. Hanno rilevato che Apollo GraphQL aveva un tempo medio di andata e ritorno inferiore dal 25 al 67% rispetto a REST per la maggior parte degli endpoint e degli scenari di carico, mentre REST scalava meglio con elevata concorrenza.

Leggilo con attenzione. È uno studio, uno stack e un solo insieme di condizioni di test. Sostiene però due conclusioni sensate:

1. Per un client su una connessione lenta o mobile, meno viaggi di andata e ritorno e payload più piccoli aiutano, e GraphQL in questo è bravo.
2. Un server GraphQL lavora di più per ogni richiesta, perché analizza, valida e risolve ogni query. Sotto un forte carico concorrente quell'overhead si vede.

Per la maggior parte delle PMI e delle startup svizzere, nessuno dei due effetti decide il progetto. La struttura del tuo database, la regione di hosting e il caching sposteranno i tempi di risposta più dello stile dell'API. Se ti serve una risposta sulle prestazioni per il tuo prodotto, misura un prototipo realistico con i tuoi dati invece di affidarti a un benchmark.

Per vedere come funziona in pratica la distribuzione in tempo reale, questa guida su REST and WebSocket data streams mostra come un'API di dati combina endpoint a richiesta e flussi dal vivo.

Caching: qui REST ha vita più facile

REST sfrutta i meccanismi nativi del web. Secondo IBM’s comparison, le API REST usano eTag e intestazioni last-modified per mettere in cache le chiamate, così browser, CDN e proxy le capiscono senza aiuto. Ogni URL è una chiave di cache.

GraphQL di solito invia le query a un unico endpoint, spesso come richieste POST, quindi il caching HTTP integrato in gran parte non si applica. IBM osserva che GraphQL può essere più difficile da mettere in cache, anche se query persistite, caching delle risposte e caching lato server aiutano. Librerie client come Apollo Client mettono inoltre in cache oggetti normalizzati sul lato client, cosa che attenua il problema nel browser.

La conseguenza pratica: se il tuo prodotto serve molti contenuti pubblici a forte prevalenza di lettura, che una CDN dovrebbe assorbire, REST è la strada che richiede meno sforzo. Se il tuo traffico è in prevalenza fatto di dati autenticati e personalizzati, il divario sul caching conta molto meno, perché quei dati non sarebbero comunque mai finiti in una cache condivisa.

Schema, tipizzazione e gestione degli errori

GraphQL richiede uno schema fortemente tipizzato scritto nel suo linguaggio di definizione degli schemi. La documentazione di AWS fa notare che questo permette al servizio di individuare molti errori nelle richieste prima ancora che il tuo codice venga eseguito. Un client che chiede un campo inesistente riceve un rifiuto chiaro. Lo schema alimenta anche documentazione, completamento automatico e generazione di codice, un vantaggio concreto per i team con sviluppatori frontend e backend separati.

REST non richiede uno schema lato server. Puoi aggiungerne uno con OpenAPI, e molti team lo fanno, ma nulla lo impone. Senza, la gestione degli errori e la validazione finiscono nel codice attorno, e i contratti tra i team possono divergere nel tempo.

Una particolarità di GraphQL sorprende chi inizia: una richiesta può restituire HTTP 200 con un risultato parziale e un elenco di errori dentro il corpo. Il tuo monitoraggio e il codice del client devono guardare dentro la risposta, non solo i codici di stato.

Aggiornamenti in tempo reale

GraphQL ha le subscription, un modo integrato per far ricevere a un client gli aggiornamenti quando i dati cambiano. IBM sottolinea che REST non ha un equivalente e si appoggia di solito a long-polling o server-sent events. In pratica le subscription viaggiano tipicamente su WebSocket, il che significa gestire un livello di connessione con stato. È infrastruttura vera da far funzionare e scalare.

Se gli aggiornamenti dal vivo sono una funzione secondaria, come un contatore di notifiche, un'API REST con server-sent events è spesso più semplice. Se i dati dal vivo sono il prodotto, come in una chat, nell'editing collaborativo o nelle dashboard, pensa prima al trasporto e poi allo stile delle interrogazioni.

I costi che GraphQL porta con sé

GraphQL sposta la complessità dal client al server. Tre questioni emergono in quasi ogni progetto.

Il problema N+1

Un server GraphQL risolve ogni campo con un resolver. Chiedi 50 ordini e il cliente di ciascuno, e un'implementazione ingenua esegue una query per gli ordini e altre 50 per i clienti. GraphQL.org’s performance guidance chiama questo il problema N+1 e consiglia il batching, per esempio con DataLoader. È risolvibile, ma qualcuno deve sapere che va risolto.

Query costose e sicurezza

Dato che sono i client a scrivere la query, possono scriverne una molto onerosa. La OWASP GraphQL Cheat Sheet avverte che query costose possono portare a un denial of service e raccomanda limiti di profondità, limiti di quantità, paginazione, timeout, analisi del costo delle query e limitazione della frequenza. Consiglia inoltre di disattivare in produzione le impostazioni predefinite insicure, come messaggi di errore troppo dettagliati e l'introspezione, e di verificare bene il controllo degli accessi. Con REST è il server a fissare quanto può costare ogni endpoint, quindi questa classe di problemi è più contenuta.

Competenze del team e strumenti

La maggior parte degli sviluppatori conosce già REST, e gli strumenti sono ovunque. IBM osserva che molte organizzazioni continuano a puntare su REST per la maturità degli strumenti e la semplicità, anche dove GraphQL sarebbe una buona opzione. Un bacino di talenti più ristretto e una curva di apprendimento più ripida fanno parte del costo di GraphQL, e questo pesa se assumi in Svizzera, dove gli ingegneri senior sono cari e rari.

Dove si colloca gRPC

Chi cerca su questo tema incontra spesso una terza opzione. gRPC viaggia su HTTP/2 e invia messaggi binari compatti definiti con i Protocol Buffers, con uno schema obbligatorio in un file .proto. Un comparison of REST, GraphQL and gRPC riassume la suddivisione abituale: REST per le API pubbliche e per tutto ciò che un browser chiama direttamente, GraphQL quando molti client hanno bisogno di porzioni diverse degli stessi dati, e gRPC tra servizi interni che controlli da entrambi i lati.

Per un sito o un'applicazione web tipica, gRPC non è la prima decisione da prendere. Diventa rilevante quando dividi un backend in più servizi che dialogano molto tra loro.

Quando usare GraphQL e quando REST è la scelta migliore

Le indicazioni di AWS sono una buona base di partenza. REST è adatto ad applicazioni più piccole con esigenze di dati meno complesse, o a client che usano dati e operazioni in modo simile. GraphQL è adatto a banda limitata, più fonti di dati o richieste eterogenee da parte dei client. Postman inquadra il compromesso come semplicità e standardizzazione per REST, contro flessibilità ed efficienza per GraphQL.

Traduci tutto questo in domande sul tuo prodotto:

• Quanti client diversi useranno l'API? Un'app web e un'app mobile con schermate simili: REST. Un'app web, due app mobili, integrazioni con partner e un chiosco, ciascuno con esigenze diverse: vale la pena guardare a GraphQL.
• Quanto sono annidati i tuoi dati? Elenchi piatti e record semplici si sposano con REST. Grafi profondi di oggetti collegati si sposano con GraphQL.
• Stai aggregando più backend? Un livello GraphQL davanti a un CRM, un ERP e un sistema di shop può offrire agli sviluppatori frontend un'unica interfaccia pulita.
• L'API è pubblica? Le API pubbliche per terze parti sono più facili da documentare, mettere in cache e limitare nella frequenza se sono REST.
• Chi se ne occuperà nel tempo? Se il tuo team è fatto di due sviluppatori e un'agenzia, vince il modello più semplice sul costo di gestione.
• Hai molto traffico in lettura su contenuti pubblici? Vincono REST e il caching su CDN.

Una via di mezzo molto diffusa

Non devi scegliere una volta per sempre. Molti prodotti mantengono REST per le risorse semplici e memorizzabili in cache e per gli endpoint pubblici, e in seguito aggiungono un livello GraphQL come gateway per i frontend complessi. Partire da un'API REST pulita e ben documentata con uno schema OpenAPI tiene aperta quella porta senza pagare il prezzo di GraphQL fin dal primo giorno.

Cosa significa per una startup o una PMI in Svizzera

La domanda che si pongono quasi tutti i fondatori non è quale sia migliore, ma quale eviti una riscrittura. La nostra risposta onesta: lo stile dell'API raramente causa riscritture. Le causano requisiti poco chiari, modelli di dati aggrovigliati ed endpoint fatti su misura una tantum. Scegli lo stile che il tuo team sa gestire bene, definisci con cura il modello dei dati e documenta il contratto.

Nel nostro lavoro ricorrono due casi. Il primo è un nuovo MVP con un solo frontend web: REST, con uno schema tipizzato, è veloce da costruire ed economico da consegnare. Il secondo è un'azienda che collega shop, CRM ed ERP esistenti in un nuovo portale: qui possono funzionare sia un livello GraphQL sia un sottile livello di integrazione con endpoint REST dedicati, e la scelta giusta dipende da quanti frontend prevedi nei prossimi due anni.

Come possiamo aiutarti

Siamo un piccolo studio di Zurigo, e gli ingegneri senior restano su ogni progetto dalla prima conversazione fino alla consegna, così la decisione sull'API la prende chi poi la costruirà e la manterrà. Realizziamo siti web, applicazioni web e mobile, piattaforme e integrazioni di sistemi, e possiamo esaminare un'API esistente o pianificare una migrazione. Se vuoi un secondo parere prima di decidere, dai un'occhiata ai nostri prezzi e alle modalità di collaborazione oppure ai progetti recenti. Per la cura continuativa, il nostro piano Run & monitor costa CHF 750 al mese e il piano Guidance, per consulenza tecnica senior, CHF 799 al mese.

Domande frequenti

GraphQL è meglio di REST?

Nessuno dei due è migliore in assoluto. GraphQL è più forte con client eterogenei, dati annidati e più fonti, mentre REST è più semplice, più facile da mettere in cache e conosciuto da praticamente ogni sviluppatore. La scelta giusta dipende dai tuoi client, dai tuoi dati e dal tuo team.

GraphQL è più veloce di REST?

Spesso sulla singola richiesta, ma non sempre su larga scala. In uno studio della University of Washington GraphQL ha mostrato tempi di risposta medi più bassi sulla maggior parte degli endpoint, mentre REST ha scalato meglio con elevata concorrenza. Prima di decidere, testa il tuo carico di lavoro reale.

Quali sono i principali pro e contro di GraphQL?

I pro sono il recupero esatto dei dati, uno schema tipizzato, meno viaggi di andata e ritorno e le subscription integrate. I contro sono un caching HTTP più difficile, il problema N+1, la necessità di limitare le query costose e una curva di apprendimento più ripida.

Posso usare GraphQL e REST insieme?

Sì. Molti team mantengono REST per gli endpoint semplici o pubblici e mettono GraphQL davanti a più servizi per i frontend complessi. Così adotti GraphQL dove conviene senza riscrivere tutto.

Fonti

• AWS AppSync documentation
• University of Washington study on GraphQL and REST performance
• IBM’s comparison
• GraphQL.org’s performance guidance
• OWASP GraphQL Cheat Sheet
• comparison of REST, GraphQL and gRPC
• Postman
• REST and WebSocket data streams