REST (Representational State Transfer) este un stil arhitectural pentru aplicații de rețea, definit de Roy Fielding. Nu este un protocol sau un standard — este un set de constrângeri care, atunci când sunt respectate, fac un API scalabil, cacheable și ușor de evoluat. Un API „RESTful" modelează totul ca resurse (utilizatori, comenzi, produse) identificate prin URI-uri și le manipulează folosind metode 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]" }
URI-ul /users/42 numește resursa; GET este acțiunea; JSON este reprezentarea. Acea combinație — substantive în path, verbe ca metode HTTP — este inima REST.
REST este stilul dominant pentru API-urile web, așa că intervievatorii folosesc această întrebare pentru a verifica dacă înțelegi de ce funcționează, nu doar că îl poți defini. Cele două constrângeri care contează cel mai mult în practică sunt statelessness (fiecare cerere este auto-conținută, așa că poți pune oricâte servere în spatele unui load balancer și scala orizontal fără sticky sessions) și uniform interface (URL-uri previzibile, orientate pe resurse, plus metode HTTP și status code-uri standard, ceea ce înseamnă că clienții nu au nevoie de logică personalizată per endpoint). Un răspuns bun conectează constrângerile de beneficii concrete — statelessness permite scalarea, cacheability reduce încărcarea, layered system îți permite să inserezi CDN-uri și gateway-uri — și notează că majoritatea API-urilor „REST" sunt pragmatice, nu pe deplin RESTful (puține implementează HATEOAS). Înțelegerea acestor constrângeri este fundația pentru orice altă decizie de design REST, de la alegerea status code-urilor până la versioning.
O bibliotecă de întrebări de interviu IT cu răspunsuri detaliate — de la Junior la Senior.
Donează