--- term: 'API di database generate automaticamente (GraphQL e REST)' seoTitle: 'API di database generate automaticamente: GraphQL e REST' headline: 'Che cosa sono le API di database generate automaticamente?' slug: api-generate-automaticamente category: database shortDefinition: 'Le API di database generate automaticamente sono le interfacce che uno strumento ricava leggendo lo schema ed espone come endpoint REST o GraphQL.' relatedTerms: - graphql-vs-rest - database-abstraction-layer - backend-boilerplate-code - backend-sdk - visual-database-management contrastsWith: - graphql-vs-rest faq: - question: 'Che cos''è un''API di database generata automaticamente?' answer: 'Un''API REST o GraphQL che una piattaforma crea da sola ispezionando lo schema del database – tabelle, colonne, tipi, relazioni – ed esponendo endpoint CRUD o resolver corrispondenti, filtri, paginazione e documentazione compresi. Il codice di backend che normalmente implementerebbe tutto questo non viene mai scritto: è derivato dallo schema e resta sincronizzato con esso.' - question: 'Come funziona davvero la generazione automatica delle API?' answer: 'Tre passaggi sotto il cofano: lo strumento ispeziona lo schema per costruire un modello di metadati di ogni tabella, colonna e relazione; mappa quel modello su una superficie di API, cioè le tabelle diventano endpoint o tipi GraphQL e le chiavi esterne diventano join o resolver annidati; e rigenera a ogni modifica dello schema, così endpoint e documentazione non divergono mai dal database. La parte "istantanea" è reale; la mappatura è il macchinario.' - question: 'Qual è la differenza tra generazione REST e GraphQL?' answer: 'La generazione REST mappa una risorsa per tabella, con parametri di query per filtrare e ordinare: semplice, memorizzabile in cache, familiare. La generazione GraphQL ricava uno schema tipizzato che permette ai client di chiedere esattamente i campi e le relazioni annidate che servono in un solo giro di rete: più forte sulle letture relazionali, con una curva di apprendimento più ripida. Le piattaforme mature generano entrambe dallo stesso schema, quindi la scelta si fa per client, non per progetto.' - question: 'Le API generate automaticamente sono sicure?' answer: 'Generata non vuol dire pronta per la produzione: la sicurezza è configurazione. Lo stack su cui c''è consenso è autenticazione con chiavi o token, controllo degli accessi basato sui ruoli, permessi a livello di riga perché ogni chiamante veda solo le proprie righe, e rate limiting davanti a tutto. Le piattaforme si distinguono soprattutto per quanta parte di quello stack sia attiva per impostazione predefinita invece che lasciata alla memoria di chi sviluppa.' - question: 'Si può aggiungere logica di business a un''API generata?' answer: 'Sì: ogni piattaforma seria offre vie d''uscita, perché il CRUD puro non copre mai un prodotto intero. Le forme più comuni sono viste e funzioni di database esposte attraverso la stessa superficie generata, hook lato server eseguiti prima o dopo le operazioni (validazione, arricchimento) ed endpoint o funzioni su misura accanto a quelli generati, per i flussi che davvero non sono CRUD.' - question: 'Esporre lo schema del database attraverso un''API è una cattiva idea?' answer: 'È la critica più forte al pattern: un''API generata accoppia i client allo schema, quindi una modifica dello schema può diventare una modifica che rompe l''API. Le mitigazioni sono note: esporre viste invece di tabelle grezze, tenere uno schema di API stabile e distinto dall''archiviazione, e mettere la logica di trasformazione negli hook. Per gli strumenti interni e il CRUD standard l''accoppiamento è di solito uno scambio equo; per le API pubbliche di contratto, il contratto va progettato di proposito.' - question: 'Quanto tempo fa risparmiare la generazione automatica?' answer: 'Il consenso del settore è minuti contro settimane. Scrivere a mano un''API CRUD di produzione per uno schema modesto – endpoint, validazione, filtri, paginazione, documentazione, test – viene stimato di routine in settimane di lavoro; la generazione lo riduce al tempo necessario a definire lo schema. Il codice risparmiato è anche manutenzione che nessuno eredita: meno superficie per bug, divergenze e revisioni di sicurezza.' - question: 'Quali strumenti open source generano API da un database?' answer: 'L''ecosistema è sano: Back4app genera automaticamente REST e GraphQL dal modello di dati; PostgREST trasforma uno schema PostgreSQL in REST; PostGraphile e pg_graphql fanno lo stesso per GraphQL; Directus, Strapi e NocoDB avvolgono la generazione in strati applicativi più ricchi. Il filo comune è l''ispezione dello schema più un modello di permessi: vanno valutati sulle impostazioni di sicurezza predefinite, non sulla demo.' codeLanguages: [javascript, dart, swift, kotlin] externalAuthorities: - name: 'PostgREST documentation' url: 'https://docs.postgrest.org/en/stable/' - name: 'Automatic API tools — curated list (GitHub)' url: 'https://github.com/dbohdan/automatic-api' - name: 'GraphQL API documentation' url: 'https://docs.parseplatform.org/graphql/guide/' - name: 'Web API design anti-pattern: exposing your database model — Shekhar Gulati' url: 'https://shekhargulati.com/2021/10/15/web-api-design-anti-pattern-exposing-your-database-model/' cta: title: 'API che non si devono mai scrivere' text: 'Su Back4app, salvare il primo oggetto crea la classe, lo schema ed entrambe le API – REST e GraphQL – con gli SDK per ogni piattaforma e i permessi applicati nel livello dati. Il backend CRUD smette semplicemente di essere codice da mantenere.' linkText: 'Inizia gratis' linkUrl: 'https://www.back4app.com/signup' author: 'Back4app Engineering' publishedDate: '2026-09-30' translationKey: auto-generated-database-apis --- **Le API di database generate automaticamente sono le interfacce che uno strumento ricava leggendo lo schema ed espone come endpoint REST o GraphQL.** Il livello CRUD – l'80 % più ripetitivo del lavoro di backend – diventa una derivazione invece di un codebase: si definiscono i dati, e la loro API esiste, documentata e sincronizzata in permanenza con lo schema. ## Punti chiave | Domanda | Risposta | | --- | --- | | Che cos'è | Endpoint REST/GraphQL ricavati dallo schema, non scritti a mano | | Come | Ispezione dello schema → modello di metadati → endpoint, resolver, documentazione | | Il guadagno | Settimane di codice CRUD diventano minuti, e zero divergenze, per sempre | | L'insidia | Generata ≠ sicura per impostazione predefinita; i permessi restano una decisione umana | | La critica | Accoppiamento allo schema, mitigato con viste, hook e una superficie di API stabile | ## Da un oggetto salvato a due API Il pattern nella sua forma più estrema: sulle piattaforme a schema flessibile perfino il passaggio dello schema è implicito. Salvare il primo oggetto crea la classe, le colonne ed entrambe le superfici di API: **JavaScript:** ```javascript // JavaScript / Node.js — Back4app JS SDK // Saving the first object creates the class, the schema, and BOTH APIs const city = new Parse.Object('City'); city.set('name', 'Lisbon'); city.set('population', 545000); await city.save(); // Instantly live — REST: GET /classes/City // GraphQL: { cities { edges { node { name } } } } ``` **Flutter:** ```dart // Flutter / Dart — Back4app Flutter SDK // Saving the first object creates the class, the schema, and both APIs final city = ParseObject('City') ..set('name', 'Lisbon') ..set('population', 545000); await city.save(); // REST and GraphQL endpoints for City now exist — nobody wrote them ``` **Swift:** ```swift // iOS / Swift — Back4app Swift SDK // Saving the first object creates the class, the schema, and both APIs var city = City() city.name = "Lisbon" city.population = 545000 city.save { result in if case .success = result { print("REST and GraphQL endpoints for City now exist") } } ``` **Kotlin:** ```kotlin // Android / Kotlin — Back4app Android SDK // Saving the first object creates the class, the schema, and both APIs val city = ParseObject("City").apply { put("name", "Lisbon") put("population", 545000) } city.saveInBackground { e -> if (e == null) Log.d("API", "REST and GraphQL endpoints for City now exist") } ``` Ed ecco che cosa è stato generato – la stessa tabella, interrogata in due modi, senza un controller scritto per nessuno dei due: ```text # REST – una risorsa per classe, filtri come parametri GET /classes/City?where={"population":{"$gt":500000}}&order=-population # GraphQL – uno schema tipizzato, i client scelgono campi e annidamento query { cities(where: { population: { greaterThan: 500000 } }) { edges { node { name population } } } } ``` ## Come funziona la generazione ```mermaid flowchart LR accTitle: Come funzionano le API di database generate automaticamente accDescr: Un generatore ispeziona lo schema del database e lo trasforma in un modello di metadati, da cui ricava endpoint REST, resolver GraphQL e documentazione; le modifiche dello schema rigenerano l'API, così nulla diverge. S["Schema del database
tabelle · tipi · relazioni"] --> I["Ispezione
modello di metadati"] I --> R["Endpoint REST
CRUD + filtri + paginazione"] I --> G["Schema GraphQL
tipi + resolver + annidamento"] I --> D["Documentazione
sempre aggiornata"] S -. "modifica dello schema" .-> I ``` La linea tratteggiata è la caratteristica più sottovalutata: poiché l'API è *derivata*, schema e API non possono contraddirsi. La classe di bug in cui documentazione, database ed endpoint raccontano ciascuno una storia diversa viene eliminata per costruzione. ## Generazione REST vs. GraphQL | Dimensione | REST generata | GraphQL generata | | --- | --- | --- | | Mappatura | Una risorsa per tabella | Uno schema tipizzato per tutto | | Letture relazionali | Più richieste o parametri di espansione | Una query, selezioni annidate | | Overfetching | Restituisce righe intere per impostazione predefinita | I client scelgono i campi esatti | | Cache | Nativa in HTTP, facile | Richiede una strategia lato client | | Documentazione | Riferimento degli endpoint | Ispezione ed explorer integrati | | Curva di apprendimento | Minuti | Una salita vera (e che vale la pena) | | Primo client ideale | Server-to-server, app semplici | UI ricche di dati, mobile su reti lente | Le piattaforme che generano entrambe da un solo schema rendono questa una scelta per client – REST per chi consuma un webhook, GraphQL per l'app mobile – e così disinnescano gran parte del dibattito GraphQL contro REST al livello CRUD. ## Sicurezza: la checklist che la generazione non copre Un'API generata è una superficie *capace*, e la cosa taglia da entrambe le parti. I punti non negoziabili: 1. **Autenticazione** su ogni richiesta – le chiavi identificano le app, le sessioni identificano gli utenti. 2. **Permessi per ruolo e a livello di classe** – quali operazioni ogni ruolo può compiere, tabella per tabella. 3. **Accesso a livello di riga** – ogni chiamante vede solo le proprie righe, applicato nel livello dati invece che affidato ai client. 4. **Rate limiting** davanti a tutto – le query generate sono query arbitrarie; il controllo dei costi resta a chi gestisce il servizio. 5. **Esporre viste, non viscere** – tutto ciò che non deve restare accoppiato ai client sta dietro una vista o un hook. Le piattaforme che vale la pena usare rendono difficile mancare le impostazioni sicure; il [modello di sicurezza di PostgREST](https://docs.postgrest.org/en/stable/) – ruoli di database più policy sulle righe – è il riferimento open source canonico per farlo nel database stesso. ## La critica onesta, e la sua risposta La [critica dell'astrazione che perde](https://shekhargulati.com/2021/10/15/web-api-design-anti-pattern-exposing-your-database-model/) è fondata: generare l'API dallo schema accoppia i client alle scelte di archiviazione, e una colonna rinominata diventa una modifica che rompe tutto. La risposta non è abbandonare la generazione, è sapere quale API si sta costruendo. Per strumenti interni, pannelli di amministrazione, MVP e backend applicativi standard (cioè la maggior parte del software, la maggior parte del tempo) il CRUD a forma di schema è esattamente ciò che serve, e scriverlo a mano ricrea lo stesso accoppiamento con più bug. Per i contratti pubblici di lunga vita conviene mettere davanti al nucleo generato una superficie progettata di proposito – viste, funzioni, endpoint su misura. La generazione copre l'80 %; le vie d'uscita esistono per il 20 %. ## Casi d'uso tipici - **Backend applicativi.** Prodotti mobile e web il cui livello dati è CRUD standard: il caso canonico, spesso sufficiente a coprire l'intera superficie di API. - **MVP e prototipi.** L'API esiste nell'istante in cui esiste lo schema; la velocità di iterazione si accumula. - **Strumenti interni e pannelli di amministrazione.** L'accesso a forma di schema è precisamente ciò che vogliono, e si sposa naturalmente con la [gestione visuale del database](/glossary/visual-database-management/). - **Modernizzazione di database legacy.** Un vecchio database guadagna una superficie REST/GraphQL moderna senza toccare il sistema che ci scrive dentro. - **Il nucleo stabile sotto la logica su misura.** CRUD generato più hook e funzioni per i flussi che sono davvero specifici del prodotto. ## Generare o scrivere a mano? Matrice decisionale | Generare quando… | Scrivere a mano quando… | | --- | --- | | L'API rispecchia il modello di dati | L'API è un contratto pubblico che deve sopravvivere alle modifiche di schema | | Il CRUD domina la superficie | Dominano i flussi che non sono CRUD | | Il vincolo è il time-to-market | In ogni endpoint c'è logica di dominio profonda | | I client sono interni o di prima parte | Terze parti integrano contro garanzie versionate | | I permessi a livello di riga coprono le regole di accesso | L'autorizzazione è essa stessa logica di business complessa | Le colonne si combinano: la forma più comune in produzione è un nucleo generato con un sottile strato progettato a mano, solo dove contratti o flussi lo esigono. ## Limiti e trade-off - **Accoppiamento allo schema.** Il trade-off principale: si mitiga con viste e hook, oppure lo si accetta consapevolmente sulle superfici di prima parte. - **Costo delle query arbitrarie.** I client possono porre domande costose; limiti di profondità, tetti di paginazione e rate limiting fanno parte del rilascio, non sono opzioni. - **Soffitto della logica di business.** Le vie d'uscita reggono flussi reali, ma un'API fatta per lo più di vie d'uscita ha superato il pattern. - **La sicurezza è configurazione.** Gli strumenti applicano ciò che viene dichiarato, e le dichiarazioni restano ingegneria. - **La disciplina sulle migrazioni resta.** La generazione elimina la divergenza delle API, non la necessità di far evolvere gli schemi con cura; una modifica di schema che rompe ora rompe in un punto solo, e si vede. ## API generate automaticamente su Back4app Back4app è una piattaforma open-source di Backend as a Service (BaaS) che combina database gestito, API REST e GraphQL generate automaticamente, autenticazione, archiviazione di file e funzioni serverless con Cloud Code. Qui la generazione è la modalità nativa della piattaforma, non una feature: il salvataggio mostrato sopra crea classe, schema ed entrambe le superfici di API in un colpo solo, [GraphQL incluso](https://docs.parseplatform.org/graphql/guide/), con gli SDK che le avvolgono su ogni piattaforma. La checklist di sicurezza arriva già come impostazione predefinita – permessi a livello di classe, ACL per singolo oggetto, rate limit – e la via d'uscita è Cloud Code: trigger e funzioni accanto al nucleo generato, così il 20 % davvero specifico gira di fianco all'80 % che non è stato scritto da nessuno.