--- term: 'CRUD (Create, Read, Update, Delete)' seoTitle: 'CRUD: che cos''è, create, read, update, delete spiegati' headline: 'Che cos''è il CRUD (create, read, update, delete)?' slug: operazioni-crud category: database shortDefinition: 'Il CRUD è l''acronimo di create, read, update e delete: le quattro operazioni di base che ogni archivio di dati persistente deve supportare.' relatedTerms: - auto-generated-database-apis - rest-api - database-queries - backend-sdk - graphql-vs-rest contrastsWith: - graphql-vs-rest faq: - question: 'Che cosa significa CRUD?' answer: 'Create, Read, Update, Delete – creare, leggere, aggiornare, eliminare: le quattro operazioni fondamentali dell''archiviazione persistente, e il minimo che qualsiasi applicazione poggiata su dati deve supportare. L''acronimo è stato diffuso da James Martin nel suo libro del 1983 Managing the Data-base Environment, con la semantica collegata formalizzata da Haim Kilov nel 1990 – ed è quindi uno dei termini più antichi ancora in uso quotidiano nel vocabolario del backend.' - question: 'Come si mappa il CRUD su SQL e su HTTP?' answer: 'Due mappature pulite che ogni sviluppatore memorizza una volta per sempre: in SQL creare è INSERT, leggere è SELECT, aggiornare è UPDATE, eliminare è DELETE. Su HTTP creare è POST, leggere è GET, aggiornare è PUT per la sostituzione completa oppure PATCH per modifiche parziali, ed eliminare è DELETE – con 201, 200 e 204 come codici di stato del percorso felice, rispettivamente.' - question: 'CRUD e REST sono la stessa cosa?' answer: 'No – rispondono a domande diverse. CRUD nomina ciò che si fa ai dati; REST è uno stile architetturale che descrive come i client interagiscono con le risorse su HTTP, con vincoli come l''assenza di stato e l''interfaccia uniforme. Gli endpoint REST si mappano spesso in modo pulito sul CRUD, ma REST può esporre azioni non CRUD, e il CRUD vive serenamente fuori da HTTP – in sessioni SQL, negli SDK e nelle code.' - question: 'Qual è la differenza fra PUT e PATCH?' answer: 'La portata dell''aggiornamento. PUT sostituisce l''intera risorsa con la rappresentazione inviata – idempotente per definizione, perché inviarla due volte produce lo stesso stato. PATCH applica una modifica parziale: cambiano solo i campi inviati. La maggior parte del traffico reale di "aggiornamento" ha la forma di un PATCH, ed è per questo che i metodi save() degli SDK inviano solo i campi modificati.' - question: 'Che cos''è un''app CRUD?' answer: 'Un''applicazione il cui ciclo centrale consiste nel creare, consultare, modificare ed eliminare record – pannelli di amministrazione, CMS, CRM, sistemi di magazzino e di prenotazione. È un termine vagamente sprezzante che non dovrebbe esserlo: la maggior parte del software aziendale è CRUD in fondo, ed è esattamente il motivo per cui le piattaforme che generano il livello CRUD in automatico eliminano così tanto lavoro.' - question: 'Che cos''è un soft delete?' answer: 'Marcare un record come eliminato – con un flag o un timestamp – invece di rimuoverlo. Preserva lo storico verificabile, l''integrità referenziale e l''annullamento, al prezzo di filtrare ogni query e complicare i vincoli di unicità. Il suo opposto, lo hard delete, è la rimozione reale, che i regimi di privacy come le richieste di cancellazione del GDPR possono davvero richiedere. Gran parte dei sistemi ha bisogno di una politica deliberata per classe, non di un comportamento predefinito.' - question: 'Quando il CRUD non basta?' answer: 'Quando il dominio riguarda eventi e storia invece dello stato corrente. L''aggiornamento in loco distrugge il passato – l''event sourcing tiene un registro in sola aggiunta e da lì deriva lo stato; CQRS separa del tutto i modelli di lettura e di scrittura. E azioni di business come "approvare la fattura" o "concludere l''ordine" sono workflow, non modifiche di righe: modellarle come semplici update nasconde il dominio. Il CRUD è il pavimento dell''accesso ai dati, non il soffitto.' - question: 'Che cosa sono varianti del CRUD come CRUDL e BREAD?' answer: 'Estensioni e riscritture della stessa idea: CRUDL aggiunge List come operazione distinta dalla lettura di un singolo record; BREAD lo compita Browse, Read, Edit, Add, Delete. Riconoscono la verità pratica che elencare collezioni – con filtri e paginazione – è un''operazione a sé, con decisioni di progetto proprie, e non semplicemente "leggere, al plurale".' codeLanguages: [javascript, dart, swift, kotlin] externalAuthorities: - name: 'Create, read, update and delete (Wikipedia)' url: 'https://en.wikipedia.org/wiki/Create,_read,_update_and_delete' - name: 'CRUD — MDN Web Docs Glossary' url: 'https://developer.mozilla.org/en-US/docs/Glossary/CRUD' - name: 'RFC 9110 — HTTP Semantics' url: 'https://www.rfc-editor.org/rfc/rfc9110' - name: 'REST API guide' url: 'https://docs.parseplatform.org/rest/guide/' cta: title: 'Il livello CRUD, già scritto' text: 'Definisci una classe su Back4app e tutta la sua superficie CRUD esiste all''istante: endpoint REST, mutation GraphQL e metodi SDK per ogni piattaforma – con permessi, hook di validazione e paginazione già integrati. I quattro verbi smettono di essere il tuo codice.' linkText: 'Inizia gratis' linkUrl: 'https://www.back4app.com/signup' author: 'Back4app Engineering' publishedDate: '2026-10-05' translationKey: crud-operations --- **Il CRUD è l'acronimo di create, read, update e delete: le quattro operazioni di base che ogni archivio di dati persistente deve supportare.** Coniato in *Managing the Data-base Environment* di James Martin (1983), resta l'acronimo più duraturo del lavoro di backend perché nomina il pavimento: qualunque altra cosa faccia il sistema, i record devono venire al mondo, essere ritrovati, cambiare e sparire. ## Punti chiave | Domanda | Risposta | | --- | --- | | I quattro verbi | Creare · Leggere · Aggiornare · Eliminare – il minimo della persistenza | | In SQL | INSERT · SELECT · UPDATE · DELETE | | Su HTTP | POST · GET · PUT/PATCH · DELETE | | vs. REST | Il CRUD è ciò che si fa ai dati; REST è il modo in cui i client raggiungono le risorse | | La mossa moderna | Il livello CRUD si genera, non si scrive | ## CRUD in quattro linguaggi ```sql -- Il CRUD in SQL: la mappatura originale INSERT INTO tasks (title) VALUES ('Write the launch post'); -- C SELECT * FROM tasks WHERE done = false; -- R UPDATE tasks SET done = true WHERE id = 42; -- U DELETE FROM tasks WHERE id = 42; -- D ``` E lo stesso ciclo nel modo in cui lo esprime un SDK – la forma che il codice applicativo scrive davvero: **JavaScript:** ```javascript // JavaScript / Node.js — Back4app JS SDK // The full CRUD cycle on one object const task = new Parse.Object('Task'); task.set('title', 'Write the launch post'); // C — create await task.save(); const fetched = await new Parse.Query('Task') .equalTo('done', false).first(); // R — read fetched.set('done', true); // U — update await fetched.save(); await fetched.destroy(); // D — delete ``` **Flutter:** ```dart // Flutter / Dart — Back4app Flutter SDK // The full CRUD cycle on one object final task = ParseObject('Task')..set('title', 'Write the launch post'); await task.save(); // C — create final query = QueryBuilder(ParseObject('Task')) ..whereEqualTo('done', false); final fetched = (await query.query()).results!.first; // R — read fetched.set('done', true); await fetched.save(); // U — update await fetched.delete(); // D — delete ``` **Swift:** ```swift // iOS / Swift — Back4app Swift SDK // The full CRUD cycle on one object var task = Task() task.title = "Write the launch post" let saved = try await task.save() // C — create let fetched = try await Task.query("done" == false) .first() // R — read var updated = fetched updated.done = true _ = try await updated.save() // U — update try await updated.delete() // D — delete ``` **Kotlin:** ```kotlin // Android / Kotlin — Back4app Android SDK // The full CRUD cycle on one object val task = ParseObject("Task").apply { put("title", "Write the launch post") } task.save() // C — create val fetched = ParseQuery.getQuery("Task") .whereEqualTo("done", false).first // R — read fetched.put("done", true) fetched.save() // U — update fetched.delete() // D — delete ``` ## Una tabella per mapparli tutti La mappatura a sei colonne che nessun singolo riferimento mette insieme: | Operazione | SQL | Verbo HTTP | Stato | Database documentale | Idioma SDK/ORM | | --- | --- | --- | --- | --- | --- | | Creare | `INSERT` | POST | 201 | `insertOne` | `object.save()` (nuovo) | | Leggere | `SELECT` | GET | 200 | `find` / `findOne` | `query.find()` / `.get()` | | Aggiornare | `UPDATE` | PUT / PATCH | 200 | `updateOne` | `object.save()` (campi modificati) | | Eliminare | `DELETE` | DELETE | 204 | `deleteOne` | `object.destroy()` | Due note a piè di pagina della [specifica HTTP](https://www.rfc-editor.org/rfc/rfc9110) che vale davvero la pena conoscere: GET è *sicuro* (nessun cambiamento di stato), PUT e DELETE sono *idempotenti* (ripetibili senza danni), POST non è né l'uno né l'altro – ed è per questo che la logica di retry li tratta in modo diverso, e perché PUT significa "sostituire tutto" mentre PATCH significa "modificare una parte". ## Dove accade il CRUD ```mermaid flowchart LR accTitle: Dove accadono le operazioni CRUD in uno stack accDescr: Un'interfaccia utente innesca chiamate SDK o HTTP; il livello API mappa i verbi sulle operazioni, applica permessi e validazione, ed esegue le istruzioni di database corrispondenti sull'archivio. UI["UI
form, elenchi, pulsanti"] --> API["Livello API
verbi → operazioni
permessi · validazione"] API --> DB[("Database
INSERT · SELECT
UPDATE · DELETE")] ``` Il diagramma è anche il promemoria di sicurezza: ogni verbo attraversa il livello API, ed è lì che permessi e validazione hanno il loro posto – una superficie CRUD senza controllo degli accessi per singola operazione è un database pubblico con qualche passaggio in più. ## CRUD vs. REST | Domanda | CRUD | REST | | --- | --- | --- | | Che cosa nomina | Operazioni sui dati | Uno stile architetturale per client e risorse | | Definito da | Quattro verbi | Vincoli: assenza di stato, interfaccia uniforme, cacheabilità… | | Dove vive | SQL, SDK, code, in qualsiasi posto | API HTTP | | Relazione | Il payload abituale degli endpoint REST | Si mappa spesso sul CRUD – ma può esporre azioni non CRUD | La lezione pratica: un'API REST è spesso un'API CRUD vestita da HTTP – ma "approvare la fattura" ha diritto di stare in un'API e non è un verbo CRUD, e il CRUD esiste tranquillamente senza HTTP all'orizzonte. I termini collaborano; non sono in concorrenza. ## Casi d'uso tipici - **L'app CRUD in senso proprio.** Pannelli di amministrazione, CMS, CRM, magazzino, prenotazioni – la maggior parte del software aziendale, con onore. - **Prototipi e MVP.** I quattro verbi su una manciata di classi *sono* la prima versione della maggior parte dei prodotti. - **API generate automaticamente.** Schema in ingresso, superficie CRUD in uscita – il default moderno che trasforma i quattro verbi in configurazione invece che in codice, trattato per esteso nella [voce sulle API generate automaticamente](/glossary/it/api-generate-automaticamente/). - **Strumenti di amministrazione e supporto.** Griglie visuali sulla stessa superficie CRUD, permessi compresi. - **Il substrato sotto tutto il resto.** Anche i sistemi event-sourced e pesanti di workflow espongono CRUD da qualche parte – impostazioni, profili, dati di riferimento. ## Ogni azione deve essere CRUD? Matrice decisionale | Modellare come CRUD quando… | Cercare qualcosa di più quando… | | --- | --- | | Lo stato corrente del record è la verità | La storia *è* il dominio → event sourcing | | La modifica è il modello mentale di chi usa il prodotto | Letture e scritture scalano in modo diverso → CQRS | | "Eliminare" può davvero rimuovere | Verifica o annullamento pretendono il soft delete | | Le modifiche concorrenti sono rare | Si profilano aggiornamenti perduti → locking ottimistico, versioni | | L'azione è "cambiare questo record" | L'azione è un verbo di business → va nominato il workflow | L'ultima riga è il design smell che vale la pena memorizzare: quando i nomi degli endpoint derivano verso `updateStatus`, il dominio sta chiedendo verbi propri. ## Limiti e trade-off - **L'aggiornamento distrugge la storia.** La mutazione in loco è l'atto fondativo del CRUD e la sua perdita fondativa: tutto ciò che ha bisogno di sapere "com'era martedì" vuole journaling o eventi. - **Eliminare è una politica, non un verbo.** Soft delete contro hard delete scambia la verificabilità con la cancellazione pretesa dai regimi di privacy e con la complessità delle query; conviene decidere per classe, in modo deliberato. - **La concorrenza non ha un prezzo esposto.** Due update, vince l'ultimo che scrive, la modifica del primo scompare in silenzio – campi di versione e salvataggi condizionali sono l'antidoto standard. - **List è il quinto verbo.** Filtri, ordinamenti e paginazione portano gran parte del traffico reale di lettura e gran parte dei bug prestazionali – è la ragione d'essere di CRUDL e BREAD. - **Le API CRUD possono diventare anemiche.** Una superficie che è solo righe-in-righe-fuori spinge la logica di business verso i client; i workflow restano lato server, accanto ai dati. ## Le operazioni CRUD 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. Il suo rapporto con questo articolo è una sottrazione: si definisce una classe e tutta la matrice CRUD qui sopra esiste di colpo – [endpoint REST](https://docs.parseplatform.org/rest/guide/) secondo la colonna HTTP, mutation GraphQL e gli idiomi SDK delle schede di codice, con i permessi a livello di classe che presidiano ogni verbo e i trigger beforeSave che si fanno carico della validazione. I quattro verbi smettono di essere la codebase e diventano il vocabolario.