A REST (Representational State Transfer) hálózati alkalmazások architektúrastílusa, amelyet Roy Fielding definiált. Nem protokoll vagy szabvány — hanem megkötések halmaza, amelyeket követve egy API skálázható, cache-elhető és könnyen továbbfejleszthető lesz. Egy "RESTful" API mindent erőforrásként (resource: userek, orderek, termékek) modellez, URI-kkal azonosítva, és standard HTTP metódusokkal manipulálja őket.
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]" }
A /users/42 URI megnevezi az erőforrást; a GET a művelet; a JSON a reprezentáció. Ez a kombináció — főnevek a path-ban, igék HTTP metódusként — a REST lényege.
A REST a webes API-k domináns stílusa, ezért az interjúztatók ezzel a kérdéssel ellenőrzik, hogy érted-e, miért működik, nem csak azt, hogy le tudod-e betűzni. A gyakorlatban legfontosabb két megkötés a statelessness (minden kérés önmagában teljes, így tetszőleges számú servert tehetsz egy load balancer mögé, és horizontálisan skálázhatsz sticky session nélkül) és a uniform interface (kiszámítható, erőforrás-orientált URL-ek plusz standard HTTP metódusok és status code-ok, ami azt jelenti, hogy a klienseknek nincs szükségük endpointonkénti egyedi logikára). Egy erős válasz konkrét előnyökhöz köti a megkötéseket — a statelessness lehetővé teszi a skálázást, a cache-elhetőség csökkenti a terhelést, a layered system lehetővé teszi CDN-ek és gateway-ek beillesztését —, és megjegyzi, hogy a legtöbb "REST" API inkább pragmatikus, mint teljesen RESTful (kevés implementál HATEOAS-t). Ezeknek a megkötéseknek a megértése minden más REST-tervezési döntés alapja, a status code-ok kiválasztásától a versioningig.
IT interjúkérdések gyűjteménye részletes válaszokkal — Juniortól Seniorig.
Adományozás