REST (Representational State Transfer) è uno stile architetturale per applicazioni in rete, definito da Roy Fielding. Non è un protocollo o uno standard — è un insieme di vincoli che, se seguiti, rendono un'API scalabile, cacheable e facile da evolvere. Un'API "RESTful" modella tutto come risorse (utenti, ordini, prodotti) identificate da URI, e le manipola usando i metodi HTTP standard.
GET /users/42 HTTP/1.1
Host: api.example.com
Accept: application/json
HTTP/1.1 200 OK
Content-Type: application/json
{ "id": 42, "name": "Ann", "email": "[email protected]" }
L'URI /users/42 nomina la risorsa; GET è l'azione; JSON è la rappresentazione. Quella combinazione — nomi nel path, verbi come metodi HTTP — è il cuore di REST.
REST è lo stile dominante per le web API, quindi gli intervistatori usano questa domanda per verificare che tu capisca perché funziona, non solo che sai scriverlo. I due vincoli che contano di più nella pratica sono la statelessness (ogni richiesta è auto-contenuta, quindi puoi mettere un numero qualsiasi di server dietro un load balancer e scalare orizzontalmente senza sticky session) e la uniform interface (URL prevedibili e orientati alle risorse più metodi HTTP e status code standard, il che significa che i client non hanno bisogno di logica custom per endpoint). Una risposta forte collega i vincoli a benefici concreti — la statelessness abilita lo scaling, la cacheability riduce il carico, il layered system ti fa inserire CDN e gateway — e nota che la maggior parte delle API "REST" è pragmatica anziché pienamente RESTful (poche implementano HATEOAS). Capire questi vincoli è la base per ogni altra decisione di design REST, dalla scelta degli status code al versioning.
Una raccolta di domande di colloquio IT con risposte dettagliate — da Junior a Senior.
Dona