Le domande sulle API REST servono a verificare se sai progettare un'interfaccia che gli altri possano usare senza sorprese. Qui sotto trovi 20 domande con risposte, dalle basi ai dettagli di progettazione che emergono nei colloqui per ruoli backend e full-stack. Per le regole sui metodi HTTP, abbiamo seguito le definizioni della RFC 9110.
Le basi
1. Che cos'è REST?
REST è uno stile architetturale per sistemi in rete, costruito attorno a risorse identificate da URL, manipolate con un piccolo insieme di operazioni standard e descritte da rappresentazioni come JSON. Un'API REST è stateless: ogni richiesta porta con sé ciò che serve al server per gestirla, quindi qualsiasi server può rispondere a qualsiasi richiesta.
2. Che cosa rende un'API "RESTful" nella pratica?
- Sostantivi per le risorse negli URL, come /orders/42, non verbi come /getOrder
- Metodi HTTP standard per le azioni
- Codici di stato significativi
- Richieste stateless
- Rappresentazioni e strutture di errore coerenti
Al colloquio, dì che poche API reali rispettano ogni vincolo REST e che il tuo obiettivo è un comportamento prevedibile.
3. A cosa servono i principali metodi HTTP?
| Metodo | Uso | Sicuro | Idempotente |
|---|---|---|---|
| GET | Legge una risorsa | Sì | Sì |
| POST | Crea una risorsa o attiva un'azione | No | No |
| PUT | Sostituisce una risorsa | No | Sì |
| PATCH | Aggiorna parzialmente una risorsa | No | Non garantito |
| DELETE | Rimuove una risorsa | No | Sì |
"Sicuro" significa che la richiesta non modifica lo stato del server. "Idempotente" significa che inviarla più volte ha lo stesso effetto che inviarla una sola volta.
4. Che cosa significa idempotente, e perché è importante?
Se una richiesta viene ripetuta, lo stato finale è lo stesso che si avrebbe dopo una sola richiesta. È importante perché le reti falliscono. Se un client va in timeout su un PUT, può riprovare senza timore. Un POST che crea un ordine potrebbe crearne due, quindi le API spesso accettano una chiave di idempotenza: il client invia una chiave univoca e il server restituisce il risultato memorizzato se rivede quella chiave.
5. PUT o PATCH?
PUT sostituisce l'intera risorsa con il body che invii, e i campi che ometti vengono cancellati o reimpostati. PATCH modifica solo i campi che invii. Usa PATCH per aggiornamenti piccoli e PUT quando il client possiede la rappresentazione completa.
Codici di stato ed errori
6. Quali codici di stato usi, e quando?
| Codice | Uso |
|---|---|
| 200 | Successo con un body |
| 201 | Creato, con un header Location per la nuova risorsa |
| 204 | Successo senza body, come una delete |
| 400 | La richiesta è malformata o non valida |
| 401 | Non autenticato |
| 403 | Autenticato ma non autorizzato |
| 404 | Risorsa non trovata |
| 409 | Conflitto con lo stato attuale, come un duplicato |
| 422 | Ben formata ma non supera la validazione |
| 429 | Troppe richieste |
| 500 | Errore del server |
| 503 | Servizio non disponibile |
Una domanda di follow-up frequente è la differenza tra 401 e 403. 401 significa "non so chi sei", mentre 403 significa "so chi sei, e non puoi farlo".
7. Come dovrebbe restituire gli errori un'API?
Usa il codice di stato giusto e un body coerente. Un buon body di errore ha un codice stabile leggibile dalla macchina, un messaggio per l'utente e, per gli errori di validazione, quali campi non sono passati. Non esporre stack trace o dettagli interni ai client.
8. Come gestisci la validazione?
Valida sul server anche se il client valida a sua volta. Restituisci tutti i problemi in una volta quando puoi, così l'utente non li corregge uno alla volta, e usa 400 o 422 in modo coerente.
Progettazione
9. Come si progettano gli URL per le relazioni?
Annida quando la risorsa figlia ha senso solo sotto quella padre, come /users/7/orders. Mantieni l'annidamento superficiale. Oltre uno o due livelli, esponi la risorsa figlia direttamente, come /orders/42, e filtra con parametri di query, come /orders?userId=7.
10. Come si pagina una lista?
| Metodo | Come funziona | Compromesso |
|---|---|---|
| Offset e limit | ?offset=40&limit=20 | Semplice, ma lento su tabelle grandi e può saltare o ripetere elementi quando i dati cambiano |
| Cursore | ?after=<token>&limit=20 | Stabile e veloce, ma non puoi saltare a pagina 50 |
| Numero di pagina | ?page=3 | Comodo per le interfacce, con gli stessi problemi dell'offset |
La paginazione a cursore è la risposta tipica per dati grandi o in rapida evoluzione. Restituisci il cursore successivo e un'indicazione sulla presenza di altri risultati.
11. Come si filtrano e ordinano i dati?
Usa parametri di query, come ?status=open&sort=-created_at. Definisci una whitelist dei campi consentiti, per evitare di esporre colonne non indicizzate o sensibili e per mantenere le query veloci.
12. Come si versiona un'API?
| Approccio | Esempio | Nota |
|---|---|---|
| Nell'URL | /v2/orders | Semplice e visibile |
| In un header | Accept: application/vnd.example.v2+json | URL più puliti, più difficile da testare nel browser |
| Parametro di query | ?version=2 | Facile, ma facile da dimenticare |
Qualunque cosa scegli, evita modifiche incompatibili all'interno di una versione. Aggiungere campi è di solito sicuro, rimuoverli o rinominarli no.
13. Cos'è HATEOAS?
Le risposte includono link ad azioni correlate, così un client può scoprire cosa può fare dopo invece di codificare gli URL in modo fisso. Fa parte della definizione di REST, ma poche API lo implementano completamente. Di' che lo conosci e che la maggior parte dei team usa la documentazione e una descrizione OpenAPI.
Sicurezza e prestazioni
14. Come si autentica un'API?
Le scelte comuni sono le API key per un semplice uso server-to-server, i bearer token come i JSON Web Token e OAuth 2.0 quando un utente concede a un'app l'accesso ai propri dati. Usa sempre HTTPS. Tieni i segreti fuori dagli URL, dato che gli URL finiscono nei log.
15. Qual è la differenza tra autenticazione e autorizzazione?
L'autenticazione consiste nel dimostrare chi sei. L'autorizzazione consiste nel decidere cosa ti è permesso fare. Falliscono in modo diverso: un token mancante o non valido è 401, un token valido senza permessi è 403.
16. Come si protegge un'API dagli abusi?
Rate limiting per chiave o per IP, limiti sulla dimensione delle richieste, validazione degli input, timeout e monitoraggio del traffico anomalo. Restituisci 429 con un header Retry-After così i client sanno quando riprovare.
17. Come funziona la cache HTTP per le API?
Le risposte possono includere header Cache-Control che indicano per quanto tempo una risposta può essere riutilizzata. Un ETag identifica una versione della risposta. Il client lo rimanda in If-None-Match, e il server risponde 304 Not Modified senza corpo se nulla è cambiato. Fa risparmiare banda e carico.
18. Cos'è il CORS?
I browser bloccano la lettura delle risposte da un'origine diversa da parte di una pagina web, a meno che il server non lo consenta. Il server invia header come Access-Control-Allow-Origin per indicare quali origini possono leggere le sue risposte. È applicato dal browser, non dal server, quindi non protegge un'API dai client non browser.
Pratica
19. REST o GraphQL o gRPC?
| Ideale per | Costo | |
|---|---|---|
| REST | API pubbliche semplici, cacheable e ampiamente comprese | Over-fetching e molti round trip per schermate complesse |
| GraphQL | Client che devono scegliere esattamente i campi e combinare dati in una sola richiesta | Maggiore complessità lato server e caching più difficile |
| gRPC | Chiamate interne veloci tra servizi con contratti rigidi | Meno adatto ai browser e all'uso pubblico |
La risposta migliore indica una situazione, non un vincitore.
20. Come si documenta e testa un'API?
Descrivila con una specifica OpenAPI, che può generare documentazione e codice client. Testa su tre livelli: unit test per la logica, integration test contro un database reale e contract test per intercettare modifiche incompatibili. Prova anche i casi di errore, come input non validi e token scaduti.
Come prepararsi
- Sii in grado di progettare una piccola API alla lavagna, come una to-do list o un sistema di ordini, con URL, metodi, status code e una risposta di errore.
- Conosci a menadito idempotenza e paginazione. Sono gli argomenti che escono più spesso.
- Prepara un racconto su un'API che hai costruito o usato, e un errore che eviteresti la prossima volta.
Per esercitarti su argomenti correlati, consulta le nostre guide alle domande di colloquio su Spring Boot, alle domande di colloquio su Node.js, alle domande di colloquio sul system design e alle domande di colloquio sul networking.
Esercitati ad alta voce e con parole tue. Una trascrizione successiva mostra dove hai divagato o saltato il punto. Rispetta le regole del datore di lavoro sugli strumenti di IA in qualsiasi colloquio o valutazione dal vivo.
Esercita le tue risposte con YesToTheOffer
Esercitati ad alta voce, ottieni risposte costruite dal tuo curriculum e rivedi la tua trascrizione in seguito. 30 minuti gratuiti, nessun abbonamento.
