---
term: 'API (interfaccia di programmazione)'
seoTitle: 'API: che cos''è un''interfaccia di programmazione e come funziona'
headline: 'Che cos''è un''API (interfaccia di programmazione)?'
slug: api
category: api-realtime
shortDefinition: 'Un''API è un insieme di regole che permette a un''applicazione di richiedere dati e funzionalità a un''altra senza conoscerne il codice interno.'
relatedTerms:
- rest-api
- graphql-vs-rest
- backend-sdk
- auto-generated-database-apis
- api-gateway-architecture
contrastsWith:
- backend-sdk
faq:
- question: 'Che cosa significa API?'
answer: 'Application Programming Interface, in italiano interfaccia di programmazione delle applicazioni. "Application" indica qualsiasi software con una funzione propria; "interface" è il contratto fra due di essi – l''insieme definito di richieste che uno può fare e di risposte che l''altro promette di restituire. La parte sulla programmazione è il punto: è un''interfaccia per il software, mentre una UI è un''interfaccia per le persone.'
- question: 'Che cos''è un''API in parole semplici?'
answer: 'Un messaggero con un menu. Un programma espone l''elenco delle cose che sa fare – recuperare questi dati, eseguire quell''azione – e altri programmi le invocano attraverso richieste definite, senza mai vedere come il lavoro avviene all''interno. L''illustrazione classica: un''app meteo non misura il cielo; chiama l''API di un servizio meteorologico.'
- question: 'Come funziona un''API?'
answer: 'Per richiesta e risposta. Il client invia una richiesta a un endpoint – un URL che nomina la risorsa – con un metodo che dichiara l''intenzione, header che portano metadati e credenziali e a volte un corpo di dati. Il server la valida, fa il lavoro e restituisce un codice di stato più un corpo di risposta, di solito JSON. Ogni integrazione mai usata si riduce a questo ciclo.'
- question: 'Quali sono alcuni esempi di API?'
answer: 'L''accesso tramite un provider di identità, il passaggio di pagamento di un checkout, una mappa incorporata in un''app di consegne, un widget meteo – ognuno è un''applicazione che chiama l''API di un''altra. Gli esempi lato sviluppo sono ancora più diretti: una piattaforma di backend che espone il database come endpoint HTTP interrogati dall''app mobile.'
- question: 'Qual è la differenza tra un''API e un SDK?'
answer: 'L''API è il contratto; un SDK è la cassetta degli attrezzi per consumarlo. Un SDK avvolge le chiamate API in funzioni idiomatiche del linguaggio e aggiunge gestione della sessione, retry e tipi. Un''API si chiama via rete; un SDK si importa nel codice – e sotto il cofano l''SDK fa chiamate API.'
- question: 'Quali sono i tipi di API?'
answer: 'Per pubblico: pubbliche (aperte a qualsiasi sviluppatore), partner (condivise con aziende sotto contratto), interne (private di una sola organizzazione) e composite (che raggruppano più chiamate). Per stile: REST, GraphQL, gRPC, SOAP e le API WebSocket. E oltre il web: le API di librerie e di sistemi operativi – le interfacce esistevano molto prima che HTTP le trasportasse.'
- question: 'Che cos''è un endpoint di un''API?'
answer: 'L''URL specifico dove un''API riceve le richieste per una risorsa: /users/42 è l''endpoint dell''utente 42. Endpoint più metodo definiscono un''operazione: GET /users/42 lo legge, DELETE /users/42 lo elimina. Gli endpoint sono la superficie indirizzabile dell''intera interfaccia.'
- question: 'Che cos''è una chiave API?'
answer: 'Una stringa generata che il client invia con ogni richiesta perché il provider identifichi il chiamante, misuri il consumo e applichi limiti o revoche. È più identificazione che autorizzazione – le API di produzione aggiungono sopra un''autenticazione vera, come i token emessi via OAuth, per i permessi per singolo utente.'
codeLanguages: [javascript, dart, swift, kotlin]
externalAuthorities:
- name: 'API — MDN Web Docs glossary'
url: 'https://developer.mozilla.org/en-US/docs/Glossary/API'
- name: 'OpenAPI Specification'
url: 'https://spec.openapis.org/oas/latest.html'
- name: 'RFC 9110 — HTTP Semantics'
url: 'https://www.rfc-editor.org/rfc/rfc9110'
- name: 'RFC 6749 — OAuth 2.0 Authorization Framework'
url: 'https://www.rfc-editor.org/rfc/rfc6749'
- name: 'API — Wikipedia'
url: 'https://en.wikipedia.org/wiki/API'
cta:
title: 'Il tuo backend, già un''API'
text: 'Definisci un modello di dati su Back4app e la piattaforma genera le API REST e GraphQL corrispondenti – endpoint, autenticazione e permessi inclusi – con SDK che le parlano in modo idiomatico da ogni piattaforma principale.'
linkText: 'Inizia gratis'
linkUrl: 'https://www.back4app.com/signup'
author: 'Back4app Engineering'
publishedDate: '2026-10-02'
translationKey: api
---
**Un'API è un insieme di regole che permette a un'applicazione di richiedere dati e funzionalità a un'altra senza conoscerne il codice interno.** La famosa analogia del ristorante – si ordina da un menu, la cucina resta invisibile – si merita la sua unica frase e niente di più, perché la cosa reale è più istruttiva della metafora: un'API è un *contratto*, e i contratti sono precisi.
## Punti chiave
| Domanda | Risposta |
| --- | --- |
| La definizione | Un contratto definito di richiesta/risposta fra due programmi |
| Il ciclo | Endpoint + metodo + header + corpo → codice di stato + risposta |
| Per pubblico | Pubblica · partner · interna · composita |
| Per stile | REST · GraphQL · gRPC · SOAP · WebSocket |
| Il contratto moderno | Una spec leggibile dalle macchine (OpenAPI) che genera documentazione, client e mock |
## Anatomia di una richiesta e di una risposta di API HTTP
Nessuna spiegazione ben posizionata ne mostra una, quindi ecco una chiamata API intera – richiesta e risposta, nulla di nascosto:
```text
POST /classes/Todo HTTP/1.1 ← metodo + endpoint
Host: api.example-backend.com
X-Api-Key: app-7f2c… ← identifica l'app che chiama
Authorization: Bearer eyJhbGci… ← autentica l'utente
Content-Type: application/json
{ "title": "Ship the release", "done": false }
HTTP/1.1 201 Created ← stato: ha funzionato, risorsa creata
Location: /classes/Todo/xKd91m
Content-Type: application/json
{ "objectId": "xKd91m", "createdAt": "2026-07-24T10:30:00Z" }
```
La stessa chiamata attraverso un SDK – che non è altro che questo HTTP, avvolto nell'idioma del linguaggio usato:
**JavaScript:**
```javascript
// JavaScript / Node.js — Back4app JS SDK
// One API call: create a record via the auto-generated REST API
const todo = new Parse.Object('Todo');
todo.set('title', 'Ship the release');
todo.set('done', false);
await todo.save();
// Under the hood: POST /classes/Todo with a JSON body → 201 Created
console.log('Created with id', todo.id);
```
**Flutter:**
```dart
// Flutter / Dart — Back4app Flutter SDK
// One API call: create a record via the auto-generated REST API
final todo = ParseObject('Todo')
..set('title', 'Ship the release')
..set('done', false);
await todo.save();
// Under the hood: POST /classes/Todo with a JSON body → 201 Created
print('Created with id ${todo.objectId}');
```
**Swift:**
```swift
// iOS / Swift — Back4app Swift SDK
// One API call: create a record via the auto-generated REST API
var todo = Todo()
todo.title = "Ship the release"
todo.done = false
todo.save { result in
// Under the hood: POST /classes/Todo with a JSON body → 201 Created
if case .success(let saved) = result { print("Created with id \(saved.id ?? "")") }
}
```
**Kotlin:**
```kotlin
// Android / Kotlin — Back4app Android SDK
// One API call: create a record via the auto-generated REST API
val todo = ParseObject("Todo")
todo.put("title", "Ship the release")
todo.put("done", false)
todo.saveInBackground { e ->
// Under the hood: POST /classes/Todo with a JSON body → 201 Created
if (e == null) println("Created with id ${todo.objectId}")
}
```
## Come funziona una chiamata API
```mermaid
flowchart LR
accTitle: Il ciclo di richiesta e risposta di un'API
accDescr: Un'applicazione client invia a un'API una richiesta con metodo, endpoint, header e corpo; l'API la valida e la autorizza, invoca la logica di backend e i dati, e restituisce al client un codice di stato con un corpo di risposta.
C["App client
(web, mobile, altro server)"] -->|"richiesta:
metodo + endpoint + header + corpo"| A["API
valida · autorizza · instrada"]
A --> B["Logica di backend
+ database"]
B --> A
A -->|"risposta:
codice di stato + JSON"| C
```
Tre proprietà di questo ciclo spiegano perché le API fanno girare lo stack moderno. **Astrazione:** al chiamante serve il contratto, mai l'implementazione – il provider può riscrivere tutto dietro l'interfaccia senza rompere un solo client. **Confine:** validazione e [permessi](/glossary/it/sicurezza-dati-vs-applicazione/) vivono all'interfaccia, ed è per questo che i client parlano alle API e mai direttamente [al database](/glossary/it/nosql-vs-sql/) – un'API non è un database; è il custode che gli sta davanti. **Composizione:** poiché ogni capacità è invocabile, le applicazioni si assemblano a partire da servizi – l'autenticazione qui, i pagamenti là, le mappe da un terzo – e sempre più gli agenti IA usano lo stesso substrato: il tool calling è chiamare API con un modello che decide le richieste.
## Il contratto: che cosa promette davvero un'API
Le pagine che definiscono un'API "un contratto" raramente ne mostrano uno. Oggi il contratto è un documento leggibile dalle macchine – l'[OpenAPI Specification](https://spec.openapis.org/oas/latest.html) è lo standard per le API HTTP – che elenca ogni endpoint, parametro, schema e codice di stato. Da quel solo file gli strumenti generano documentazione di riferimento, librerie client, stub di server, server mock e test di contratto.
L'inquadramento contrattuale ha denti grazie al *versionamento*. Aggiungere un campo alla risposta non rompe nessuno; rinominarlo o rimuoverlo rompe in silenzio ogni consumatore – per questo le API mature distinguono le modifiche additive da quelle che rompono, versionano la propria superficie (`/v1/`, oppure tramite header) e pubblicano finestre di deprecazione. Un'API senza una politica di cambiamento è un contratto senza clausole: tecnicamente una promessa, in pratica una sorpresa.
## I tipi di API
In forma di query, perché "tipi di API" è una ricerca a sé: due tassonomie, non una.
**Per pubblico:**
| Tipo | Consumatori | Preoccupazioni tipiche |
| --- | --- | --- |
| Pubblica (aperta) | Qualsiasi sviluppatore registrato | Chiavi, quote, qualità della documentazione, disciplina di versionamento |
| Partner | Aziende sotto contratto | Accordi legali, SLA, autenticazione più stretta |
| Interna (privata) | I team e i servizi della propria organizzazione | Contratti fra microservizi, cicli di cambiamento più rapidi |
| Composita | Client che hanno bisogno di pacchetti | Una chiamata che ne orchestra diverse – meno giri di rete |
**Per stile:** [REST](/glossary/it/api-rest/) (risorse a degli URL, metodi HTTP), GraphQL (query modellate dal client su un solo endpoint), gRPC (binario, contract-first, da servizio a servizio), SOAP (buste XML, standard enterprise/legacy) e le API WebSocket ([bidirezionali, persistenti](/glossary/it/websockets/)) – confrontate nella tabella seguente.
E un paragrafo che le spiegazioni sul web saltano: non ogni API è un'API web. La libreria standard di un linguaggio, le chiamate di sistema POSIX e le interfacce `fetch` e di geolocalizzazione integrate nel browser sono tutte API – contratti fra programmi – che non attraversano mai una rete. La variante web ha soltanto messo il contratto dietro un URL.
## REST vs. GraphQL vs. gRPC vs. SOAP vs. WebSocket
| Stile | Formato sul filo | Modello | Punto di forza | Attenzione a |
| --- | --- | --- | --- | --- |
| REST | JSON su HTTP | Risorse + metodi | API CRUD pubbliche, cacheabilità, ubiquità | Over/underfetching su forme fisse |
| GraphQL | JSON su HTTP | Query composte dal client | Client diversi, dati annidati | Complessità della cache, N+1 dei resolver |
| gRPC | Protobuf su HTTP/2 | Chiamate di procedura tipizzate | Velocità interna da servizio a servizio | Frizione nel browser, debug binario |
| SOAP | Buste XML | Operazioni + standard WS-* | Enterprise legacy, contratti formali | Verbosità, peso degli strumenti |
| WebSocket | Frame su un solo socket | Messaggi bidirezionali | Push in tempo reale, presenza | Il protocollo va definito da zero |
## Casi d'uso tipici
- **Backend mobile e web** – i dati di ogni schermata arrivano attraverso un'API; il frontend non tocca mai il database.
- **Integrazione di terze parti** – pagamenti, identità, messaggistica, mappe: capacità affittate tramite contratti invece di essere ricostruite.
- **Comunicazione fra microservizi** – le API interne come le cuciture che permettono ai servizi di essere rilasciati e scalati in modo indipendente.
- **Automazione e scripting** – tutto ciò che ha un'API si può orchestrare: pipeline di CI, infrastruttura, flussi di contenuti.
- **Agenti IA e tool calling** – i modelli agiscono invocando API; un contratto bene documentato è ormai consumato due volte dalle macchine, dagli SDK e dagli agenti.
## Quale stile di API scegliere? Matrice decisionale
| Situazione | Scegliere |
| --- | --- |
| CRUD pubblico su risorse | REST – la lingua franca, amica della cache |
| Molti tipi di client, ognuno con forme diverse | I selection set di GraphQL |
| Maglia interna di servizi a throughput elevato | Contratti gRPC |
| Tempo reale, bidirezionale, sempre connesso | WebSocket (o uno strato di live query al di sopra) |
| Partner enterprise con requisiti WS-* | SOAP – perché lo dice il contratto |
| Una schermata che ha bisogno di cinque servizi | Un endpoint composito o un backend-for-frontend |
## Limiti e trade-off
- **Un contratto lega anche il provider.** Ogni campo pubblicato diventa qualcosa da cui qualcuno dipende; l'evoluzione passa dalla disciplina di versionamento, non da modifiche silenziose.
- **Le API di rete ereditano la rete.** Latenza, guasti parziali e retry fanno parte della semantica di ogni chiamata remota – le chiamate di funzione locali non hanno mai avuto bisogno di politiche di timeout.
- **L'astrazione nasconde il costo.** Una chiamata dall'aspetto innocente può diramarsi in lavoro costoso; i consumatori vedono il menu, non il conto della cucina – ed è a questo che servono i [rate limit](/glossary/it/rate-limiting-api/) e le quote.
- **La superficie di sicurezza cresce con la superficie esposta.** Ogni endpoint è una porta; le chiavi identificano ma non autorizzano, quindi un'autenticazione vera (token in stile [OAuth 2.0](https://www.rfc-editor.org/rfc/rfc6749), permessi per singolo utente) e la validazione degli input sono il minimo indispensabile.
- **Le forme fisse non calzano a tutti i consumatori.** I trade-off di overfetching e underfetching nel design degli endpoint sono un argomento a sé – si veda [la voce gemella](/glossary/overfetching-underfetching/).
## Le API 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 mossa che definisce tutto è che l'API è *generata, non costruita*: si definisce un modello di dati e la piattaforma lo espone subito come [endpoint REST e schema GraphQL](/glossary/it/api-generate-automaticamente/) – la chiamata sezionata qui sopra è il vero formato che Back4app scambia sulla rete – con chiavi, token utente e permessi a livello di classe che fanno rispettare il contratto al confine. Gli [SDK](/glossary/backend-sdk/) consumano quell'API in modo idiomatico da ogni piattaforma principale, e le operazioni su misura diventano funzioni Cloud Code: nuovi endpoint in un file, la stessa disciplina di contratto, nessun server da far girare.