REST vs GraphQL: qual è la differenza e quale usare?

REST e GraphQL sono due modi di progettare un'API: il modo concordato con cui le schermate della tua app (o altri programmi) chiedono dati al tuo backend. Con REST c'è un URL separato per ogni tipo di oggetto, come /customers o /orders, e ciascuno restituisce una struttura di dati prestabilita. Con GraphQL di solito c'è un solo URL, e chi chiama invia una query che elenca esattamente quali campi vuole ricevere. Per la maggior parte delle app create con l'AI, REST è la scelta predefinita più semplice e migliore.

Perché conta quando costruisci con l'AI

Quando chiedi a un app builder AI «un'app con un backend», deve scegliere come comunicano frontend e backend. Non devi decidere ogni volta, ma vedrai questi termini nel codice, nella documentazione e quando ti colleghi a servizi esterni. Alcuni servizi offrono un solo stile: molti espongono API REST, mentre altri — Shopify e GitHub, per esempio — offrono o privilegiano anche GraphQL. Conoscere la differenza ti aiuta a capire cosa stai guardando ed evitare di aggiungere complessità che non ti serve. Se il termine «API» ti è nuovo, parti da cos'è un'API.

Un'analogia quotidiana

REST è un menu fisso al ristorante. Ogni piatto (endpoint) arriva come lo ha pensato la cucina. Ordini il piatto «cliente» e ricevi tutto il vassoio — nome, email, indirizzo, data di iscrizione — anche se volevi solo il nome. Vuoi anche gli ordini recenti del cliente? È un secondo piatto.

GraphQL è ordinare alla carta dallo stesso cameriere. Scrivi esattamente cosa vuoi: «il nome del cliente e le date e i totali dei suoi ultimi tre ordini». Un ordine, un vassoio, solo ciò che hai chiesto. Ma la cucina deve essere attrezzata per gestire qualsiasi combinazione i clienti possano scrivere.

La stessa richiesta, in entrambi i modi

Supponi che una pagina cliente abbia bisogno del nome di un cliente e dei suoi tre ordini più recenti.

Con REST, di solito servono due richieste:

GET /api/customers/42
GET /api/customers/42/orders?limit=3

La prima risposta potrebbe includere più di quanto serve alla pagina:

{ "id": 42, "name": "Lena Park", "email": "lena@example.com", "address": "…", "createdAt": "…" }

Con GraphQL, è una sola richiesta, di solito un POST a un unico endpoint come /graphql, con una query:

query {
  customer(id: 42) {
    name
    orders(last: 3) {
      date
      total
    }
  }
}

E la risposta rispecchia esattamente la query:

{
  "data": {
    "customer": {
      "name": "Lena Park",
      "orders": [
        { "date": "2026-09-20", "total": 48.0 },
        { "date": "2026-09-02", "total": 19.5 },
        { "date": "2026-08-15", "total": 72.25 }
      ]
    }
  }
}

Entrambi restituiscono JSON. La differenza è chi decide la forma: in REST decide il server; in GraphQL decide chi chiama, entro ciò che lo schema del server consente.

Confronto diretto

Dove si adatta ciascuno

Scegli REST quando:

• Stai costruendo un'app tipica: un sistema di prenotazioni, un CRM, una dashboard, un negozio.
• Un frontend parla con un backend, e controlli entrambi.
• Vuoi la soluzione più semplice da debuggare, mettere in cache e proteggere.
• Altri servizi chiameranno la tua app (webhook e la maggior parte delle integrazioni si aspettano endpoint in stile REST).

Considera GraphQL quando:

• Più client diversi — un sito web, un'app mobile, integrazioni con partner — hanno bisogno di porzioni molto diverse degli stessi dati.
• I tuoi dati sono fortemente collegati (prodotti, varianti, recensioni, venditori, inventario) e le schermate devono combinarli in molti modi.
• Stai usando un servizio che offre GraphQL come API principale.

Una regola utile: se non sei sicuro di aver bisogno di GraphQL, probabilmente non ne hai ancora bisogno. È più facile aggiungerlo in seguito che rimuoverlo.

Termini chiave

Idee sbagliate comuni

• «GraphQL è più recente, quindi è migliore». Risolve problemi specifici. Per una singola app con un solo frontend, spesso aggiunge lavoro senza grandi benefici.
• «GraphQL è un database». No. È un livello API; dietro di esso il server legge comunque dal tuo database.
• «GraphQL è sempre più veloce». Meno richieste possono aiutare sulle reti mobili lente, ma una query senza limiti può caricare enormi quantità di dati. Le prestazioni dipendono dal backend.
• «REST significa uno standard rigido». In pratica «API REST» indica in modo approssimativo URL di risorse, metodi HTTP e JSON. Molte buone API piegano le regole formali.
• «Stato 200 vuol dire che ha funzionato». Con GraphQL controlla il campo errors: una richiesta può fallire in parte e restituire comunque 200.

Cosa chiedere al tuo app builder AI

• «Usa un'API REST semplice con JSON, a meno che non ci sia un motivo chiaro per non farlo — spiega se pensi che serva GraphQL.»
• «Elenca ogni endpoint, cosa restituisce e chi è autorizzato a chiamarlo.»
• «Per la pagina cliente, restituisci solo i campi che la pagina usa.»
• «Aggiungi la paginazione agli endpoint di lista, così non restituiscono mai migliaia di righe in una volta.»
• «Questo servizio ha solo un'API GraphQL — chiamala dal server, tieni la chiave in un segreto e richiedi solo i campi che servono.»
• «Restituisci codici di stato HTTP corretti e messaggi di errore in JSON.»

REST e GraphQL in Mythex

La documentazione di Mythex include una ricetta per costruire un backend API REST con un prompt di partenza, e un backend può girare in Node, Python (FastAPI), C# o Java accanto alla tua app web. La documentazione non descrive un template GraphQL, quindi se ne vuoi uno, chiedilo esplicitamente e spiega il motivo. Chiamare un'API GraphQL di terze parti funziona come qualsiasi altro servizio esterno — vedi integrare qualsiasi API. Letture correlate: frontend vs backend e come creare un'API REST.

Domande