REST (Representational State Transfer) to styl architektoniczny dla aplikacji sieciowych, zdefiniowany przez Roya Fieldinga. To nie protokół ani standard — to zestaw ograniczeń (constraints), które, gdy się ich przestrzega, czynią API skalowalnym, cache'owalnym i łatwym do rozwijania. API „RESTful" modeluje wszystko jako zasoby (resources) (użytkownicy, zamówienia, produkty) identyfikowane przez URI i manipuluje nimi za pomocą standardowych metod HTTP.
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 /users/42 nazywa zasób; GET to akcja; JSON to reprezentacja. To połączenie — rzeczowniki w ścieżce, czasowniki jako metody HTTP — jest sercem REST.
REST to dominujący styl dla webowych API, więc rozmówcy używają tego pytania, by sprawdzić, czy rozumiesz, dlaczego działa, a nie tylko czy potrafisz je przeliterować. Dwa ograniczenia najważniejsze w praktyce to bezstanowość (każde żądanie jest samowystarczalne, więc możesz postawić dowolną liczbę serwerów za load balancerem i skalować poziomo bez sticky sessions) oraz jednolity interfejs (przewidywalne, zorientowane na zasoby URL-e plus standardowe metody HTTP i kody statusu, co oznacza, że klienci nie potrzebują niestandardowej logiki per endpoint). Mocna odpowiedź łączy ograniczenia z konkretnymi korzyściami — bezstanowość umożliwia skalowanie, cache'owalność redukuje obciążenie, system warstwowy pozwala wstawiać CDN-y i bramy — i zauważa, że większość API „REST" jest pragmatyczna, a nie w pełni RESTful (mało które implementuje HATEOAS). Zrozumienie tych ograniczeń jest fundamentem każdej innej decyzji projektowej REST, od wyboru kodów statusu po wersjonowanie.
Biblioteka pytań rekrutacyjnych IT ze szczegółowymi odpowiedziami — od Juniora do Seniora.
Wesprzyj