REST (Representational State Transfer) është një stil arkitekturor për aplikacione në rrjet, i përcaktuar nga Roy Fielding. Nuk është një protokoll apo standard — është një grup kufizimesh (constraints) që, kur ndiqen, e bëjnë një API të shkallëzueshëm (scalable), të cache-ueshëm, dhe të lehtë për t'u zhvilluar. Një API "RESTful" i modelon të gjitha si resources (users, orders, products) të identifikuara nga URI, dhe i manipulon duke përdorur HTTP methods standarde.
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-ja /users/42 e emërton resource-in; GET është veprimi; JSON është representation-i. Ai kombinim — emra në path, folje si HTTP methods — është zemra e REST-it.
REST është stili dominues për web API, prandaj intervistuesit e përdorin këtë pyetje për të kontrolluar nëse kupton pse funksionon, jo thjesht se di ta shqiptosh. Dy kufizimet që kanë më shumë rëndësi në praktikë janë statelessness (çdo request është i vetëmjaftueshëm, kështu që mund të vendosësh sa server të duash pas një load balancer-i dhe të shkallëzosh horizontalisht pa sticky sessions) dhe uniform interface (URL të parashikueshme e të orientuara nga resource-t plus HTTP methods dhe status codes standarde, që do të thotë se client-ët nuk kanë nevojë për logjikë të veçantë për çdo endpoint). Një përgjigje e fortë i lidh kufizimet me përfitime konkrete — statelessness mundëson scaling, cacheability ul ngarkesën, layered system të lejon të fusësh CDN dhe gateway — dhe vëren se shumica e API-ve "REST" janë pragmatike sesa plotësisht RESTful (pak prej tyre implementojnë HATEOAS). Të kuptosh këto kufizime është themeli për çdo vendim tjetër dizajni REST, nga zgjedhja e status codes deri te versioning.
Një bibliotekë pyetjesh intervistash IT me përgjigje të detajuara — nga Junior te Senior.
Dhuro