REST

Styl projektowania API oparty na protokole HTTP, w którym operacje na zasobach wykonuje się metodami GET, POST, PUT i DELETE. Bezstanowy i szeroko stosowany w usługach sieciowych.

REST (Representational State Transfer) to styl architektoniczny projektowania API, w którym wszystko, co interesujące w systemie, traktujesz jako zasób (np. użytkownik, zamówienie, artykuł) dostępny pod własnym adresem URL. Na tych zasobach operujesz standardowymi metodami protokołu HTTP, a serwer odsyła ich reprezentację — najczęściej w formacie JSON. Pojęcie opisał Roy Fielding w 2000 roku w swojej rozprawie doktorskiej i od tamtej pory REST stał się domyślnym sposobem dogadywania się aplikacji przez sieć.

Sednem REST jest mapowanie czasowników HTTP na akcje: GET pobiera zasób, POST tworzy nowy, PUT aktualizuje (zwykle podmienia całość), PATCH aktualizuje częściowo, a DELETE usuwa. Adres mówi na czym działasz, metoda mówi co robisz. Do tego dochodzą kody statusu (200 OK, 201 Created, 404 Not Found, 500), które od razu komunikują, jak poszło.

Kluczowa cecha to bezstanowość (stateless): każde żądanie musi zawierać komplet informacji potrzebnych do jego obsługi — serwer nie pamięta, co wysłałeś przed chwilą. Dzięki temu łatwo skalujesz aplikację horyzontalnie, bo dowolny serwer obsłuży dowolne żądanie. Stan sesji trzymasz po stronie klienta, np. w tokenie w nagłówku Authorization.

Przykład z praktyki

Załóżmy, że budujesz API sklepu. Listę produktów pobierzesz prostym poleceniem w terminalu:

curl -X GET https://api.sklep.pl/products

Konkretny produkt o ID 42 to GET /products/42, nowy dodasz przez POST /products z ciałem w JSON, a skasujesz przez DELETE /products/42. Zwróć uwagę na konwencję: w ścieżkach używamy rzeczowników w liczbie mnogiej (/products), nie czasowników typu /getProduct — czasownik jest już w metodzie HTTP. Do testowania świetnie sprawdzą się narzędzia takie jak Postman, Insomnia albo zwykły curl.

Częste błędy i mity

  • Mit „REST = JSON po HTTP”. Samo wystawienie endpointów to jeszcze nie REST. Prawdziwie restowe API powinno m.in. używać metod zgodnie z ich znaczeniem i być bezstanowe. Większość „REST API” w praktyce jest tylko RESTish — i to zwykle wystarcza.
  • Mylenie PUT z POST. PUT jest idempotentny (dziesięć identycznych żądań daje ten sam efekt co jedno), POST nie — dlatego podwójne kliknięcie „Kup” potrafi utworzyć dwa zamówienia.
  • Czasowniki w URL. /deleteUser/5 zamiast DELETE /users/5 to klasyk juniora.
  • Ignorowanie kodów statusu. Odsyłanie 200 OK z komunikatem o błędzie w treści to proszenie się o kłopoty.

Warto znać pojęcia powiązane: HTTP i jego metody, JSON, API, CRUD (Create-Read-Update-Delete, które ładnie mapuje się na metody HTTP), endpoint, idempotentność oraz alternatywy takie jak GraphQL i gRPC, gdy REST zaczyna uwierać.