Domande e risposte sui colloqui REST API (Guida 2026)

Le REST API alimentano gran parte delle integrazioni su internet. Che tu stia puntando a un ruolo backend, full stack o da software engineer, è probabile che ti vengano poste domande su design di REST API, metodi HTTP e pattern di autenticazione.

In questa guida ti accompagnerò attraverso le domande che gli intervistatori fanno davvero. Le ho organizzate per livello di difficoltà e tipo di ruolo, così puoi concentrarti su ciò che conta di più per la posizione che desideri. Ogni risposta include esempi pratici e, quando rilevante, snippet di codice che puoi adattare.

Una cosa da tenere a mente: gli intervistatori testano molto più spesso i fondamenti rispetto agli argomenti avanzati. Se domini le basi (metodi HTTP, codici di stato, statelessness), affronterai la maggior parte dei colloqui sulle REST API con sicurezza. I pattern architetturali più sofisticati vengono dopo.

Domande di base sui colloqui REST API

Queste domande verificano le tue conoscenze fondamentali. Aspettale in quasi ogni colloquio, a prescindere dalla seniority.

1. Che cos'è REST e quali sono i suoi vincoli?

REST sta per Representational State Transfer. È uno stile architetturale per progettare applicazioni di rete, definito da Roy Fielding nella sua tesi di dottorato del 2000.

REST ha sei vincoli:

1. Client-Server: Separazione delle responsabilità tra interfaccia utente e archiviazione dati
2. Stateless: Ogni richiesta contiene tutte le informazioni necessarie per completarla
3. Cacheable: Le risposte devono indicare se possono essere messe in cache
4. Layered System: I componenti non possono vedere oltre il loro livello immediato
5. Uniform Interface: Modalità standardizzata di interagire con le risorse
6. Code-on-Demand (opzionale): I server possono inviare codice eseguibile ai client

2. Qual è la differenza tra REST e SOAP?

REST è uno stile architetturale; SOAP è un protocollo. REST usa tipicamente JSON su HTTP e sfrutta i metodi HTTP standard. SOAP usa esclusivamente XML e definisce un proprio formato di messaggistica con buste e intestazioni.

SOAP ha ancora senso per sistemi enterprise che richiedono contratti formali (WSDL) o sicurezza a livello di messaggio (WS-Security).

3. Cosa sono i metodi HTTP e quando si usa ciascuno?

I metodi HTTP definiscono l'azione da eseguire su una risorsa.

4. Qual è la differenza tra PUT e POST?

POST crea una nuova risorsa in cui il server determina l'URI. PUT sostituisce una risorsa a uno specifico URI che il client specifica.

POST /users          → Server creates user, returns /users/123
PUT /users/123       → Client specifies URI, replaces entire resource

Se fai PUT su un URI che non esiste, il server può crearlo. Se fai PUT su un URI esistente, sostituisci l'intera risorsa.

5. Qual è la differenza tra PUT e PATCH?

PUT sostituisce l'intera risorsa. PATCH applica modifiche parziali.

# PUT replaces everything
PUT /users/123
{"name": "Khalid", "email": "khalid@example.com", "role": "admin"}

# PATCH updates only specified fields
PATCH /users/123
{"role": "admin"}

6. Cosa significa "stateless" in REST?

Stateless significa che ogni richiesta deve contenere tutte le informazioni che il server necessita per elaborarla. Il server non memorizza alcun contesto del client tra una richiesta e l'altra.

Questo significa niente sessioni lato server. Se un utente è autenticato, il client deve inviare le credenziali (tipicamente un token) con ogni richiesta.

7. Cosa rende un'API RESTful?

Un'API è davvero RESTful quando rispetta tutti i vincoli REST, incluso HATEOAS (Hypermedia as the Engine of Application State). In pratica, la maggior parte delle API che si definiscono "REST" sono in realtà "simili a REST" o al Livello 2 del Richardson Maturity Model. E onestamente, va bene per la maggior parte dei casi d'uso.

Livelli del Richardson Maturity Model per le REST API. Immagine dell'autore.

8. Quali sono i codici di stato HTTP di base che dovresti conoscere?

Dovresti conoscere almeno questi sette codici essenziali che coprono la maggior parte degli scenari API:

9. Qual è la differenza tra una risorsa e un endpoint?

Una risorsa è l'entità dati (utente, ordine, prodotto). Un endpoint è il percorso URL che fornisce accesso a quella risorsa.

Resource: User
Endpoints: GET /users, GET /users/123, POST /users

10. Quali sono le best practice per il design degli URI?

Usa nomi (sostantivi), non verbi. Mantieni gli URI in minuscolo con trattini per i nomi composti. Usa sostantivi plurali per le collezioni.

Good:  /users, /users/123, /order-items
Bad:   /getUsers, /Users, /order_items

Evita annidamenti profondi. Invece di /users/123/posts/456/comments/789, considera /comments/789 o /comments?post_id=456.

11. Cos'è l'idempotenza e quali metodi HTTP sono idempotenti?

Un'operazione è idempotente se eseguirla più volte produce lo stesso risultato che eseguirla una sola volta.

Un PATCH che imposta un valore è idempotente; un PATCH che incrementa un contatore non lo è.

12. Qual è la differenza tra metodi safe e idempotenti?

I metodi safe non modificano le risorse (GET, HEAD, OPTIONS). I metodi idempotenti possono essere chiamati più volte con lo stesso effetto (GET, PUT, DELETE).

Tutti i metodi safe sono idempotenti, ma non tutti i metodi idempotenti sono safe. DELETE è idempotente ma non safe perché modifica lo stato.

13. Quando usare parametri di query rispetto ai parametri di path?

I parametri di path identificano una specifica risorsa. I parametri di query filtrano, ordinano o paginano collezioni.

Path:   /users/123              (specific user)
Query:  /users?status=active    (filtered collection)
        /users?sort=name&limit=10

14. Cos'è la negoziazione dei contenuti?

La negoziazione dei contenuti consente ai client di richiedere diverse rappresentazioni di una risorsa. Il client invia un header Accept e il server risponde con il formato appropriato.

Accept: application/json    → Server returns JSON
Accept: application/xml     → Server returns XML

15. A cosa serve il metodo OPTIONS?

OPTIONS restituisce i metodi HTTP che un server supporta per un URL specifico. I browser lo usano per le richieste di preflight CORS per verificare se le richieste cross-origin sono consentite.

Domande intermedie sulle REST API

Queste domande testano l'applicazione pratica e il processo decisionale. Aspettale per posizioni di livello intermedio.

16. Qual è la differenza tra 401 e 403?

Questa è la coppia di codici più comunemente confusa. Ho visto ingegneri senior invertirli nelle code review.

401 Unauthorized

Significa non autenticato. Il server non sa chi sei. La tua risposta dovrebbe invitare l'utente ad accedere.

403 Forbidden

Significa non autorizzato. Il server sa chi sei ma non hai i permessi. Rieseguire l'autenticazione non aiuterà.

Diagramma decisionale: errore di autenticazione vs autorizzazione. Immagine dell'autore.

17. Qual è la differenza tra 400 e 422?

Ecco esempi che illustrano la differenza:

400 Bad Request

Indica sintassi malformata. Il server non può analizzare la richiesta (struttura JSON non valida, header obbligatori mancanti).

422 Unprocessable Entity

Indica sintassi valida ma errori semantici. Il JSON è valido ma i dati falliscono la validazione (formato email non valido, password troppo corta).

# 400: Cannot parse
{"name": "Khalid",}  # Trailing comma breaks JSON

# 422: Valid JSON, invalid data
{"email": "not-an-email"}  # Fails validation

18. Quando dovresti usare 409 Conflict?

Usa 409 quando la richiesta è in conflitto con lo stato attuale della risorsa:

• Fallimenti di locking ottimistico (mismatch ETag)
• Violazioni di vincoli di unicità (username duplicato)
• Transizioni di stato non valide (annullare un ordine già spedito)

19. Come implementi la paginazione?

Due approcci principali:

Paginazione basata su offset

Semplice ma con problemi di performance su dataset grandi.

GET /users?limit=20&offset=40

Paginazione basata su cursore

Scala meglio ed evita il "page drift" quando i dati cambiano.

GET /users?limit=20&cursor=eyJpZCI6MTIzfQ

Aziende come Stripe, GitHub e Slack usano la paginazione a cursore per dataset di grandi dimensioni.

20. Quali sono le strategie comuni di versionamento API?

Ci sono tre approcci principali, ciascuno con compromessi diversi:

Versionamento nell'URI

È il più comune. È esplicito e facile da fare debug.

GET /v1/users
GET /v2/users

Versionamento negli header

URL più puliti ma più difficile da testare nei browser.

GET /users
Accept-Version: v2

Versionamento con parametri di query

Facile da aggiungere ma appesantisce gli URL.

GET /users?version=2

21. Cos'è un ETag e come funziona il caching?

Un ETag è un identificatore di versione per una risorsa. Il server lo invia nelle risposte; il client lo reinvia nelle richieste successive per verificare se la risorsa è cambiata.

# First request
GET /users/123
Response: ETag: "abc123"

# Subsequent request
GET /users/123
If-None-Match: "abc123"
Response: 304 Not Modified (if unchanged)

22. Quali metodi di autenticazione si usano per le REST API?

I quattro metodi di autenticazione più comuni sono API Keys, Bearer Token, OAuth 2.0 e JWT:

23. Cos'è JWT e come funziona?

JWT (JSON Web Token) è composto da tre parti: Header, Payload e Signature. Scopri di più su lavorare con JSON in Python.

Header: {"alg": "RS256", "typ": "JWT"}
Payload: {"sub": "user123", "exp": 1704153600}
Signature: RSASHA256(base64(header) + "." + base64(payload), privateKey)

Il server firma il token; i client lo inviano con le richieste. Il server valida la firma senza consultare il database.

24. Qual è la differenza tra RS256 e HS256?

HS256 (simmetrico): La stessa secret firma e verifica. Rischioso se più servizi devono verificare i token.

RS256 (asimmetrico): La chiave privata firma, la chiave pubblica verifica. Consigliato per sistemi distribuiti in cui più servizi validano i token.

25. Cos'è HATEOAS?

HATEOAS (Hypermedia as the Engine of Application State) significa che le risposte includono link ad azioni e risorse correlate.

{
  "id": 123,
  "name": "Khalid",
  "links": [
    {"rel": "self", "href": "/users/123"},
    {"rel": "orders", "href": "/users/123/orders"}
  ]
}

In pratica, la maggior parte delle API non implementa HATEOAS completamente. Conosci il concetto ma non aspettarti di implementarlo nella maggior parte dei lavori. Anche le grandi aziende tech raramente costruiscono API pienamente conformi a HATEOAS.

26. Come gestisci gli errori in modo coerente?

Usa il formato RFC 7807 Problem Details per risposte di errore coerenti:

{
  "type": "https://api.example.com/errors/validation",
  "title": "Validation Error",
  "status": 422,
  "detail": "Email format is invalid",
  "instance": "/users"
}

27. Cos'è il rate limiting e perché è importante?

Il rate limiting protegge la tua API da abusi e garantisce un uso equo. Risposta comune:

HTTP/1.1 429 Too Many Requests
Retry-After: 3600
X-RateLimit-Limit: 1000
X-RateLimit-Remaining: 0

28. Come progetti filtraggio e ordinamento?

Usa parametri di query con convenzioni chiare:

# Filtering
GET /products?category=electronics&price[gte]=100&price[lte]=500

# Sorting (prefix - for descending)
GET /users?sort=-created_at,name

Domande avanzate sulle REST API

Queste domande verificano il pensiero architetturale. Aspettale per posizioni senior.

29. Cosa è cambiato tra OAuth 2.0 e OAuth 2.1?

OAuth 2.1 consolida le best practice di sicurezza:

Il punto chiave: usa il flusso Authorization Code con PKCE per tutti i tipi di client.

30. Come implementi l'idempotenza per endpoint di pagamento?

Usa chiavi di idempotenza per rendere sicuri i retry dei POST:

async def handle_payment(request: Request, payment: PaymentCreate):
    idempotency_key = request.headers.get("Idempotency-Key")
    
    # Check if already processed
    cached = await redis.get(f"idem:{idempotency_key}")
    if cached:
        return JSONResponse(json.loads(cached))
    
    # Process payment
    result = await process_payment(payment)
    
    # Cache result (24-hour TTL)
    await redis.setex(f"idem:{idempotency_key}", 86400, json.dumps(result))
    return result

Il client genera un UUID e lo invia con la richiesta. Se arriva di nuovo la stessa chiave, restituisci la risposta in cache.

31. Come progetteresti un rate limiter distribuito?

Per sistemi distribuiti, non puoi usare contatori in memoria perché il traffico è bilanciato tra istanze. Questo è un tranello comune che mette in difficoltà i candidati.

Architettura:

1. Usa Redis per l'archiviazione centralizzata dei contatori
2. Implementa l'algoritmo Token Bucket per tollerare i burst
3. Usa operazioni atomiche (script Lua) per prevenire race condition

# Pseudocode for Token Bucket
tokens = redis.get(user_id) or max_tokens
if tokens > 0:
    redis.decr(user_id)
    process_request()
else:
    return 429

32. Quando sceglieresti gRPC invece di REST?

Scegli gRPC per:

• Comunicazione interna tra microservizi (throughput 5-10x)
• Requisiti di streaming in tempo reale
• Mobile-to-backend con vincoli di banda
• Ambienti poliglotti che necessitano di contratti rigidi

Scegli REST per:

• API pubbliche con consumatori eterogenei
• Applicazioni web (supporto universale dei browser)
• Operazioni CRUD semplici
• Team non familiari con Protocol Buffers

33. Come gestisci operazioni di lunga durata?

Usa il pattern di richiesta asincrona:

1. Il client invia la richiesta

2. Il server restituisce 202 Accepted con un URL di stato

3. Il client interroga l'URL di stato fino al completamento

POST /reports
Response: 202 Accepted
Location: /reports/abc123/status

GET /reports/abc123/status
Response: {"status": "processing", "progress": 45}

GET /reports/abc123/status
Response: {"status": "completed", "result_url": "/reports/abc123"}

34. Cos'è il pattern Saga?

Saga gestisce transazioni distribuite tra microservizi senza locking. Ogni servizio esegue una transazione locale e pubblica un evento. Se un passaggio fallisce, transazioni compensative annullano i passaggi precedenti.

Order Created → Payment Processed → Inventory Reserved → Order Confirmed
                     ↓ (failure)
              Release Payment → Cancel Order

35. Quali sono le vulnerabilità di sicurezza comuni dei JWT?

Confusione dell'algoritmo: l'attaccante cambia RS256 in HS256 e firma con la chiave pubblica. Soluzione: metti sempre in whitelist gli algoritmi.

# Vulnerable
jwt.decode(token, key)

# Secure
jwt.decode(token, key, algorithms=["RS256"])

Algoritmo "none": l'attaccante rimuove completamente la firma. Soluzione: rifiuta l'algoritmo "none".

Domande REST API per Backend Developer

36. Cos'è il problema N+1 query?

Il problema N+1 si verifica quando recuperi N record ed esegui una query separata per la relazione di ciascun record.

# N+1 Problem: 101 queries for 100 users
users = User.query.all()  # 1 query
for user in users:
    print(user.posts)     # 100 queries

Soluzioni:

Django: usa select_related() per le foreign key, prefetch_related() per le many-to-many.

# 2 queries instead of 101
users = User.objects.prefetch_related('posts').all()

SQLAlchemy: usa joinedload() o selectinload().

37. Come configuri il connection pooling?

Il connection pooling riutilizza le connessioni al database invece di crearne di nuove per ogni richiesta.

# SQLAlchemy
engine = create_engine(
    "postgresql://user:pass@host/db",
    pool_size=5,           # Permanent connections
    max_overflow=10,       # Temporary overflow
    pool_timeout=30,       # Wait timeout
    pool_pre_ping=True     # Validate before use
)

38. Quali strategie di caching conosci?

Ci sono tre strategie di caching principali, ciascuna ottimizzata per diversi pattern di accesso:

39. Come implementi la verifica della firma dei webhook?

import hmac
import hashlib

def verify_webhook(payload: bytes, signature: str, secret: str) -> bool:
    expected = 'sha256=' + hmac.new(
        secret.encode(),
        payload,
        hashlib.sha256
    ).hexdigest()
    return hmac.compare_digest(expected, signature)

40. Quali metriche indicano la salute di un'API?

Dovresti monitorare queste quattro metriche chiave per valutare la salute della tua API:

Domande REST API per Full Stack Developer

41. Quando un browser invia una richiesta di preflight CORS?

I browser inviano un OPTIONS di preflight per:

• Metodi diversi da GET, HEAD, POST
• Header personalizzati (Authorization, X-API-Key)
• Content-Type diverso da form-urlencoded, multipart/form-data, text/plain

42. Come configuri il CORS in modo sicuro?

// Express.js
app.use(cors({
  origin: ['https://yourdomain.com'],  // Never use * with credentials
  credentials: true,
  methods: ['GET', 'POST', 'PUT', 'DELETE'],
  allowedHeaders: ['Content-Type', 'Authorization']
}));

Non usare mai il jolly (*) con le credenziali. Non consentire mai l'origine null.

43. Dove dovresti archiviare i token sul client?

La conservazione dei token comporta compromessi di sicurezza tra vulnerabilità XSS e CSRF"

Best practice: conserva i refresh token in cookie HttpOnly con SameSite=Strict. Tieni gli access token in memoria.

44. Quando dovresti usare WebSocket rispetto a SSE?

La scelta dipende dal fatto che ti serva comunicazione bidirezionale e da come vuoi gestire la riconnessione:

Usa SSE per notifiche, feed in tempo reale, ticker azionari. Usa WebSocket per chat, giochi multiplayer, editing collaborativo.

45. Come gestisci gli upload di file?

Per file grandi, usa upload a chunk con tracciamento dei progressi:

async function chunkedUpload(file, chunkSize = 5 * 1024 * 1024) {
  const totalChunks = Math.ceil(file.size / chunkSize);
  
  for (let i = 0; i < totalChunks; i++) {
    const chunk = file.slice(i * chunkSize, (i + 1) * chunkSize);
    await uploadChunk(uploadId, i, chunk);
  }
}

Domande REST API basate su scenari

46. Progetta una REST API per un sistema di prenotazione hotel

Risorse:

• /hotels - Elenco e ricerca hotel

• /hotels/{id}/rooms - Camere disponibili

• /bookings - Creare e gestire prenotazioni

• /guests/{id} - Profili ospite

Decisioni chiave:

• Usa paginazione a cursore per la ricerca hotel
• Implementa locking ottimistico per la disponibilità delle camere
• Restituisci 409 Conflict per tentativi di doppia prenotazione
• Usa chiavi di idempotenza per l'elaborazione dei pagamenti

47. Come implementeresti i soft delete?

Aggiungi un timestamp deleted_at invece di rimuovere i record:

@app.delete("/users/{user_id}")
def delete_user(user_id: int):
    user = db.get(user_id)
    user.deleted_at = datetime.utcnow()
    db.commit()
    return Response(status_code=204)

@app.get("/users")
def list_users(include_deleted: bool = False):
    query = User.query
    if not include_deleted:
        query = query.filter(User.deleted_at.is_(None))
    return query.all()

48. Come migri da v1 a v2 senza rompere i client?

Usa il pattern Strangler Fig:

1. Distribuisci v2 insieme a v1
2. Instrada le nuove funzionalità a v2
3. Migra gradualmente gli endpoint esistenti
4. Comunica la deprecazione tramite header Sunset
5. Rimuovi v1 dopo il periodo di migrazione

49. Come progetteresti un'API di ricerca con filtri complessi?

Per una ricerca prodotti con filtri multipli:

GET /products?q=laptop&category=electronics&price[gte]=500&price[lte]=2000&brand=apple,dell&in_stock=true&sort=-rating&limit=20&cursor=abc123

Decisioni di design:

• Usa Elasticsearch per la ricerca full-text (i DB relazionali faticano con il fuzzy matching)
• Implementa la ricerca a faccette per mostrare le opzioni di filtro disponibili
• Restituisci i conteggi dei filtri così gli utenti sanno quanti risultati produce ciascun filtro
• Metti in cache le combinazioni di ricerca popolari

50. Come gestisci il versionamento API in un'architettura a microservizi?

Opzioni:

1. Versionamento a livello di gateway: l'API gateway instrada /v1/* ai servizi vecchi, /v2/* ai nuovi

2. Versionamento a livello di servizio: ogni servizio gestisce la propria negoziazione di versione

3. Contratti guidati dai consumatori: usa Pact o strumenti simili per garantire compatibilità

Per la maggior parte dei team, il versionamento a livello di gateway offre la separazione più pulita.

51. Come implementeresti il rate limiting per diversi livelli di utenti?

La soluzione prevede di definire limiti specifici per livello e verificarli usando contatori Redis:

RATE_LIMITS = {
    "free": {"requests": 100, "window": 3600},
    "pro": {"requests": 1000, "window": 3600},
    "enterprise": {"requests": 10000, "window": 3600}
}

async def rate_limit_middleware(request: Request):
    user = get_current_user(request)
    tier = user.subscription_tier
    limits = RATE_LIMITS[tier]
    
    key = f"rate:{user.id}:{current_hour()}"
    count = await redis.incr(key)
    
    if count == 1:
        await redis.expire(key, limits["window"])
    
    if count > limits["requests"]:
        raise HTTPException(
            status_code=429,
            headers={
                "X-RateLimit-Limit": str(limits["requests"]),
                "X-RateLimit-Remaining": "0",
                "Retry-After": str(seconds_until_reset())
            }
        )

Domande comportamentali sulle REST API

52. Spiega REST a una persona non tecnica

"Pensa a una REST API come a un cameriere in un ristorante. Tu (il cliente) non puoi andare direttamente in cucina. Invece, dici al cameriere cosa vuoi dal menù, e lui te lo porta. Il menù è come la documentazione dell'API, che elenca cosa puoi ordinare. Il cameriere segue regole precise: chiedi qualcosa (GET), ordini qualcosa di nuovo (POST) o rimandi indietro qualcosa (DELETE). Se in cucina è finito qualcosa, il cameriere te lo dice (404 Not Found) così non aspetti all'infinito."

Questa analogia funziona sorprendentemente bene nelle riunioni con gli stakeholder.

53. Descrivi una volta in cui hai ottimizzato un'API

Usa il metodo STAR:

• Situazione: "La nostra API di ricerca aveva tempi di risposta di 3 secondi durante i picchi di traffico"
• Compito: "Dovevo ridurre la latenza senza grandi cambiamenti architetturali"
• Azione: "Ho aggiunto caching Redis per le query frequenti, implementato la paginazione a cursore e aggiunto indici al database"
• Risultato: "Il tempo di risposta è sceso a 200 ms e abbiamo gestito 5x più traffico"

54. Come comunichi breaking changes ai consumatori dell'API?

1. Annuncia in anticipo: dai almeno 6-12 mesi di preavviso per i cambiamenti maggiori

2. Usa l'header Sunset: Sunset: Sat, 31 Dec 2026 23:59:59 GMT

3. Fornisci guide di migrazione: documenta esattamente cosa cambia e come adattarsi

4. Mantieni entrambe le versioni: tieni in esecuzione la versione vecchia durante la transizione

5. Monitora l'uso: traccia quali client sono ancora sulla vecchia versione

55. Quale documentazione crei per le API?

La documentazione essenziale include:

• Specifica OpenAPI/Swagger: contratto leggibile dalle macchine
• Guida rapida: prima chiamata API in meno di 5 minuti
• Guida all'autenticazione: come ottenere e usare le credenziali
• Riferimento errori: tutti i possibili codici d'errore e come gestirli
• Changelog: cosa è cambiato in ogni versione
• Documentazione rate limit: limiti per tier e come gestire i 429

56. Quando NON useresti REST?

REST non è sempre la scelta giusta. Sapere quando usare alternative dimostra maturità architetturale. Ho visto team forzare REST in casi d'uso in cui crea più problemi che soluzioni.

Riferimento rapido REST API

Usa questa sezione come consultazione rapida quando devi verificare le proprietà dei metodi HTTP, i codici di stato o pattern comuni durante la preparazione ai colloqui o nello sviluppo reale.

Confronto dei metodi HTTP

Questa tabella riassume le proprietà chiave di ciascun metodo HTTP, aiu

Riferimento codici di stato

Ecco i codici di stato HTTP più usati, organizzati per categoria. Concentrati nel capire quando usarli piuttosto che memorizzare l'intera specifica.

2xx Success

• 200 OK: GET, PUT, PATCH riusciti
• 201 Created: POST riuscito (includi header Location)
• 204 No Content: DELETE riuscito

4xx Client Errors

• 400 Bad Request: sintassi malformata
• 401 Unauthorized: autenticazione richiesta
• 403 Forbidden: autenticato ma non autorizzato
• 404 Not Found: la risorsa non esiste
• 409 Conflict: conflitto di stato
• 422 Unprocessable Entity: errore di validazione
• 429 Too Many Requests: limitato dal rate

5xx Server Errors

• 500 Internal Server Error: errore generico del server
• 502 Bad Gateway: errore del server a monte
• 503 Service Unavailable: temporaneamente sovraccarico

Errori comuni da evitare

Anche sviluppatori esperti cadono in queste trappole. Fai attenzione a questi errori comuni quando progetti o implementi REST API:

• Usare verbi negli URL (ad es. /getUsers invece di /users)

• Restituire 200 OK per stati di errore, che rompe la gestione degli errori lato client

• Confondere 401 e 403 (Autenticazione vs. Autorizzazione)

• Annidare eccessivamente gli URL oltre due livelli

• Conservare i token in localStorage (crea vulnerabilità XSS)

• Ignorare l'idempotenza per le richieste POST

• Restituire messaggi di errore generici senza dettagli utili

Conclusione

So che memorizzare definizioni non ti garantirà di superare ogni colloquio tecnico. La realtà è che l'ingegneria nel mondo reale spesso richiede di infrangere le "regole" rigide di cui abbiamo appena parlato, e agli intervistatori interessa più il tuo ragionamento che la tua capacità di recitare le specifiche RFC. Per ruoli altamente specializzati, una profonda conoscenza del dominio o l'esperienza con framework specifici può comunque essere il fattore decisivo.

Ma padroneggiare questi fondamenti REST conta anche se non incontrerai esattamente queste domande. Funziona come una mappa per capire come opera il web moderno. Quando ti viene chiesto di progettare un nuovo sistema o di fare debug di un incidente in produzione, capire la distinzione tra un 401 e un 403 (come ho spiegato prima) ti dà la chiarezza per risolvere i problemi più velocemente. Riconoscerai esattamente perché standardizzare le interazioni della tua API, non solo scrivere codice che funziona, è il segno distintivo di un ingegnere senior.

Se vuoi approfondire la costruzione di questi sistemi, dai un'occhiata al nostro corso Introduction to APIs in Python.