---
term: 'SDK backend (software development kit)'
seoTitle: 'SDK backend: che cos''è e differenze fra SDK e API'
headline: 'Che cos''è un SDK backend?'
slug: sdk-backend
category: api-realtime
shortDefinition: 'Un SDK backend è un kit di librerie e utilità che permette alle app di parlare con un servizio di backend nel proprio linguaggio, senza HTTP grezzo.'
relatedTerms:
  - baas-vs-custom-backend
  - auto-generated-database-apis
  - database-abstraction-layer
  - backend-boilerplate-code
contrastsWith:
  - auto-generated-database-apis
faq:
  - question: 'Che cos''è un SDK, in parole semplici?'
    answer: 'Un software development kit: l''insieme di librerie, documentazione e strumenti che rende pratico costruire su una piattaforma. Un SDK backend è il membro della famiglia che vive sul client – la libreria che trasforma l''API HTTP di un servizio di backend in metodi nativi e oggetti tipizzati nel linguaggio dell''app stessa.'
  - question: 'Che differenza c''è fra un SDK e un''API?'
    answer: 'L''API è il contratto – gli endpoint, i parametri e le risposte che un servizio espone. L''SDK è il kit che parla quel contratto al posto di chi sviluppa: metodi nativi che compongono le richieste, agganciano l''autenticazione, analizzano le risposte trasformandole in oggetti tipizzati e gestiscono gli errori. Un''API si può sempre usare senza il suo SDK; l''SDK esiste perché raramente convenga farlo.'
  - question: 'Che cosa fa davvero un SDK backend sotto il cofano?'
    answer: 'L''impalcatura che altrimenti andrebbe riscritta a ogni chiamata: comporre l''URL e codificare i parametri, agganciare le chiavi dell''app e il session token dell''utente, serializzare e deserializzare fra oggetti nativi e JSON, tradurre gli errori HTTP in eccezioni tipizzate, ritentare con criterio e conservare lo stato della sessione fra una chiamata e l''altra. Una chiamata di metodo nel linguaggio dell''app; sotto, uno scambio HTTP corretto e autenticato.'
  - question: 'Che differenza c''è fra un SDK client e un SDK server?'
    answer: 'La fiducia. Un SDK client viaggia dentro le app che gli utenti tengono in mano, quindi porta solo chiavi pubblicabili e ogni richiesta viene verificata contro i permessi sul server. Un SDK server gira in ambienti sotto il proprio controllo e può detenere credenziali privilegiate che scavalcano quelle verifiche. Confondere i due – spedire una chiave privilegiata dentro un''app – è il classico fallimento di sicurezza degli SDK.'
  - question: 'Che differenza c''è fra un SDK, una libreria e un framework?'
    answer: 'Una libreria è codice che si chiama; un framework è codice che chiama il nostro, imponendo una struttura. Un SDK è un kit – di norma una o più librerie più documentazione, strumenti ed esempi – rivolto a una sola piattaforma o a un solo servizio. Ogni SDK contiene librerie; non ogni libreria è un SDK; i framework invertono il controllo in un modo che nessuno dei due condivide.'
  - question: 'Quando conviene usare HTTP grezzo invece dell''SDK?'
    answer: 'Quando l''SDK non si adatta all''ambiente: un linguaggio non supportato, vincoli estremi sulla dimensione del binario, runtime edge dove ogni dipendenza pesa, oppure un SDK non più mantenuto che resta indietro rispetto all''API. HTTP grezzo è sempre possibile contro un''API documentata – torna però in carico l''impalcatura che l''SDK assorbiva, quindi va trattato come una scelta deliberata, non come un''opzione predefinita.'
  - question: 'Cosa rende buono un SDK?'
    answer: 'Sembra nativo in ciascun linguaggio invece che tradotto a macchina; è tipizzato, documentato e allineato all''API; gli errori sono azionabili; autenticazione e ritentativi sono invisibili; e il suo ingombro è proporzionato. La spia sono i primi dieci minuti: un buon SDK porta dall''installazione alla prima chiamata riuscita in una schermata di codice.'
  - question: 'Le piattaforme di backend hanno bisogno di un SDK per ogni piattaforma?'
    answer: 'Quelle serie ne distribuiscono una famiglia – web, le piattaforme mobile e i linguaggi server più diffusi – perché ogni ecosistema si aspetta i propri idiomi, i propri pattern asincroni e il proprio sistema di tipi. La copertura è un criterio di selezione concreto: l''API di una piattaforma è usabile solo quanto l''SDK per la piattaforma su cui si sta costruendo.'
codeLanguages: [javascript, dart, swift, kotlin]
externalAuthorities:
  - name: 'Software development kit (Wikipedia)'
    url: 'https://en.wikipedia.org/wiki/Software_development_kit'
  - name: 'SDK documentation hub'
    url: 'https://docs.parseplatform.org/'
  - name: 'JavaScript SDK guide'
    url: 'https://docs.parseplatform.org/js/guide/'
  - name: 'Back4app SDK quickstarts'
    url: 'https://www.back4app.com/docs'
cta:
  title: 'Un solo backend, nativo su ogni piattaforma'
  text: 'Back4app distribuisce SDK open source per JavaScript, Flutter, Swift, Kotlin e altri – oggetti tipizzati, gestione della sessione, query, file e aggiornamenti in tempo reale come idiomi nativi su ogni piattaforma, tutti rivolti allo stesso backend.'
  linkText: 'Inizia gratis'
  linkUrl: 'https://www.back4app.com/signup'
author: 'Back4app Engineering'
publishedDate: '2026-10-19'
translationKey: backend-sdk
---

**Un SDK backend è un kit di librerie e utilità che permette alle app di parlare con un servizio di backend nel proprio linguaggio, senza HTTP grezzo.** L'API è il contratto; l'SDK è chi lo parla correntemente – e la distanza fra i due si misura nel codice di impalcatura che l'app non contiene più.

## Punti chiave

| Domanda | Risposta |
| --- | --- |
| SDK vs. API | API = il contratto; SDK = il kit che lo parla in modo nativo |
| Che cosa assorbe | URL, header di autenticazione, serializzazione, errori, retry, stato della sessione |
| SDK client vs. server | Chiavi pubblicabili + permessi applicati vs. codice fidato e privilegiato |
| vs. libreria/framework | Un kit di librerie per una piattaforma; i framework invertono il controllo |
| Criteri di scelta | Copertura dei linguaggi, tipizzazione, ritmo di manutenzione, rapidità della prima chiamata |

## L'impalcatura, prima e dopo

Quanto costa una sola query in HTTP grezzo:

```javascript
// HTTP grezzo: ogni chiamata reimplementa l'impalcatura
const res = await fetch(
  'https://parseapi.back4app.com/classes/Order?where=' +
    encodeURIComponent(JSON.stringify({ status: 'paid' })),
  {
    headers: {
      'X-Parse-Application-Id': APP_ID,
      'X-Parse-REST-API-Key': REST_KEY,
      'X-Parse-Session-Token': sessionToken,   // recuperato e salvato… a mano
    },
  }
);
if (!res.ok) handleHttpError(res.status);       // tradotto in che cosa, esattamente?
const orders = (await res.json()).results.map(hydrateOrder); // tipizzazione: a mano
```

La stessa chiamata attraverso l'SDK – con sessione, serializzazione ed errori gestiti all'interno:

**JavaScript:**

```javascript
// JavaScript / Node.js — Back4app JS SDK
// One SDK call — session auth, serialization, retries all inside it
const query = new Parse.Query('Order');
query.equalTo('status', 'paid');
const orders = await query.find();
// The raw-HTTP version of this: build the URL, attach headers and
// session token, encode the where-clause, parse JSON, map types…
```

**Flutter:**

```dart
// Flutter / Dart — Back4app Flutter SDK
// One SDK call — session auth, serialization, retries all inside it
final query = QueryBuilder<ParseObject>(ParseObject('Order'))
  ..whereEqualTo('status', 'paid');
final response = await query.query();
// Typed objects out; headers, tokens, and JSON handled inside the SDK
```

**Swift:**

```swift
// iOS / Swift — Back4app Swift SDK
// One SDK call — session auth, serialization, retries all inside it
let query = Order.query("status" == "paid")
query.find { result in
  if case .success(let orders) = result {
    render(orders)   // typed structs out; HTTP plumbing inside the SDK
  }
}
```

**Kotlin:**

```kotlin
// Android / Kotlin — Back4app Android SDK
// One SDK call — session auth, serialization, retries all inside it
val query = ParseQuery.getQuery<ParseObject>("Order")
query.whereEqualTo("status", "paid")
query.findInBackground { orders, e ->
  if (e == null) render(orders) // typed objects out; plumbing inside the SDK
}
```

## Dove si colloca l'SDK

```mermaid
flowchart LR
  accTitle: Come un SDK backend collega un'app a un servizio
  accDescr: Il codice dell'applicazione chiama i metodi nativi dell'SDK; l'SDK compone richieste HTTP autenticate verso l'API del servizio di backend e riconverte le risposte in oggetti tipizzati per l'app.
  A["Codice dell'app<br/>metodi nativi, oggetti tipizzati"] --> S["SDK<br/>auth · serializzazione ·<br/>errori · retry · sessione"]
  S -->|"HTTPS"| API["API backend<br/>REST / GraphQL"]
  API --> B["Servizio di backend"]
```

## SDK vs. API vs. libreria vs. framework

| Concetto | Che cos'è | Chi chiama chi | Forma tipica |
| --- | --- | --- | --- |
| API | Il contratto del servizio sulla rete | La si chiama (in un modo o nell'altro) | Endpoint + JSON |
| **SDK** | **Kit che parla il contratto di una piattaforma** | **Lo si chiama, in modo nativo** | **Libreria + documentazione + strumenti** |
| Libreria | Codice riutilizzabile per un compito | La si chiama | Un pacchetto per analizzare le date |
| Framework | Struttura che esegue il nostro codice | Chiama lui | Un framework web o di UI |

E la distinzione che porta il peso della sicurezza – **SDK client vs. SDK server**:

| Dimensione | SDK client | SDK server |
| --- | --- | --- |
| Dove gira | Dispositivi e browser degli utenti | Infrastruttura sotto il proprio controllo |
| Credenziali | Solo chiavi dell'app pubblicabili | Può detenere chiavi privilegiate |
| Permessi | Applicati sul server a ogni richiesta (ACL, CLP) | Può essere autorizzato a scavalcarli |
| Regola d'oro | **Niente di segreto viaggia al suo interno** | **Le sue chiavi non lasciano mai il server** |

La breccia classica in questo vocabolario: una chiave server privilegiata incollata "temporaneamente" dentro un'app mobile. Gli SDK client sono progettati partendo dal presupposto che tutto ciò che contengono sia pubblico – ed è per questo che la sicurezza vera risiede nel [livello dei dati](/glossary/it/sicurezza-dati-vs-applicazione/), non nel binario.

## Casi d'uso tipici

- **App mobile e web su un BaaS** – l'SDK *è* l'interfaccia del backend: autenticazione, dati, file e aggiornamenti in tempo reale come chiamate native.
- **Consumo di servizi di terze parti** – pagamenti, messaggistica, analytics: l'SDK del fornitore risparmia i dettagli del suo HTTP.
- **Integrazione da server a servizio** – SDK server dotati di credenziali privilegiate che svolgono lavoro amministrativo in ambienti fidati.
- **Prodotti multipiattaforma** – un backend, quattro SDK, quattro idiomi nativi – le schede di codice qui sopra mostrano una sola query in quattro ecosistemi.
- **Team di piattaforma interni** – avvolgere le API di casa in SDK sottili, così che i team di prodotto non riscrivano mai due volte l'impalcatura a mano.

## SDK o HTTP grezzo? Matrice decisionale

| Usare l'SDK quando… | Passare a HTTP grezzo quando… |
| --- | --- |
| La piattaforma è coperta e mantenuta | Il linguaggio non ha un SDK (ancora vivo) |
| Autenticazione e gestione della sessione contano | Si tratta di una singola chiamata non autenticata |
| Servono oggetti ed errori tipizzati | La dimensione del binario si conta in kilobyte |
| Il team mescola livelli di esperienza diversi | Si sta costruendo un *proprio* livello di SDK |
| La velocità conta più del controllo | L'SDK resta indietro rispetto all'API che serve oggi |

L'inquadramento onesto: HTTP grezzo resta sempre disponibile contro un'API documentata – l'SDK è una comodità dai rendimenti cumulativi, non un lucchetto. Meglio preferire le piattaforme i cui SDK sono open source, così che la comodità non diventi mai una scatola nera.

## Limiti e trade-off

- **Un SDK è una dipendenza con un ciclo di vita.** Versioni, breaking change e deprecazioni arrivano secondo il calendario del fornitore; conviene fissare le versioni, leggere i changelog e preferire chi pubblica con disciplina semver.
- **L'astrazione nasconde la rete.** Quando qualcosa si comporta male, il debug passa attraverso il livello dell'SDK – quelli buoni scrivono log; quelli eccellenti sono open source, così si può leggere la verità.
- **La copertura è disomogenea.** L'SDK del linguaggio di punta è spesso eccellente mentre la coda lunga resta indietro; va valutato l'SDK della piattaforma *di destinazione*, non le schermate della documentazione.
- **Il peso del bundle conta davvero sui client.** I budget mobile e web contano i kilobyte; gli SDK modulari e compatibili con il tree-shaking si guadagnano il posto.
- **L'SDK non può riparare l'API.** Un contratto confuso produce un kit confuso – la qualità di un SDK discende dalla progettazione dell'API.

## Gli SDK 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. La famiglia di SDK ne è la porta d'ingresso: [kit open source](https://docs.parseplatform.org/) per JavaScript, Flutter, Swift, Kotlin/Android e altri, ognuno dei quali avvolge le stesse API generate in idiomi nativi – oggetti tipizzati, gestione della sessione, query con include, caricamento di file e sottoscrizioni in tempo reale. Gli SDK client portano solo chiavi pubblicabili, con ACL e permessi di classe applicati sul server a ogni chiamata; il lavoro privilegiato resta in Cloud Code. Un solo backend, tutte le piattaforme, e nessuna impalcatura nei repository.