Historia i filozofia REST

Wyobraź sobie, że musisz zamówić pizzę przez telefon. Dzwonisz do pizzerii, podajesz swój adres, wybierasz składniki, płacisz i czekasz na dostawę. Każde zamówienie to oddzielna rozmowa — pizza nie pamięta poprzednich rozmów. To właśnie zasada działania REST API.

Rewolucja, która zmieniła internet

W 2000 roku Roy Fielding, współtwórca protokołu HTTP, opublikował rozprawę doktorską, która na zawsze zmieniła sposób, w jaki aplikacje komunikują się przez internet. Opisał w niej REST (Representational State Transfer) — zbiór zasad, które dziś napędzają praktycznie każde API, z którym masz do czynienia.

Przed REST dominował SOAP — protokół tak skomplikowany, że programiści żartowali: "SOAP to jak wysyłanie listu w trzech kopertach z instrukcją obsługi". Każde zapytanie wymagało kilkudziesięciu linii XML-a, specjalnych bibliotek i generowania kodu z plików WSDL.

XML

<!-- Przykład zapytania SOAP - tylko po to, żeby pobrać listę produktów! -->
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <GetProducts xmlns="http://tempuri.org/">
      <categoryId>1</categoryId>
    </GetProducts>
  </soap:Body>
</soap:Envelope>

Porównaj to z zapytaniem REST:

Tekst

GET /api/products?category=1

Sześć zasad, które rządzą internetem

Fielding sformułował sześć ograniczeń architektury RESTful. Każde z nich ma praktyczne konsekwencje w codziennej pracy:

1. Klient-serwer

Twoja aplikacja React (klient) tylko wyświetla dane i zbiera input od użytkownika. Serwer Node.js obsługuje logikę biznesową i bazę danych. Możesz zmienić frontend z React na Vue bez dotykania backendu.

2. Bezstanowość (Stateless)

Najważniejsza zasada w praktyce. Każde zapytanie do /api/users/123 musi zawierać token autoryzacji. Serwer nie pamięta, że 5 sekund temu ten sam użytkownik już się zalogował.

Wskazówka: Dlatego w nagłówkach HTTP zawsze przesyłasz Authorization: Bearer jwt_token_tutaj przy każdym zapytaniu wymagającym uwierzytelnienia.

3. Możliwość cachowania

Odpowiedzi są oznaczone nagłówkami Cache-Control, ETag. Dzięki temu CDN-y mogą przechowywać statyczne dane przez godziny, a przeglądarki nie pobierają ponownie niezmienionego profilu użytkownika.

4. Jednolity interfejs

GET /users zwraca listę, POST /users tworzy nowego, PUT /users/123 aktualizuje, DELETE /users/123 usuwa. Intuicyjne i przewidywalne dla każdego programisty.

5. System warstwowy

Twoja aplikacja mobilna nie wie, czy łączy się bezpośrednio z serwerem produkcyjnym, czy przez load balancer, Cloudflare, czy cache Redis. Po prostu wywołuje https://api.sklep.pl/products.

6. Kod na żądanie (opcjonalne)

Rzadko stosowane w praktyce. Przykład: serwer może wysłać JavaScript do walidacji formularza po stronie klienta.

Dlaczego REST wygrał z SOAP?

Liczby mówią wszystko:

Zapytanie SOAP: 500-1500 znaków XML-a
Zapytanie REST: 20-50 znaków w URL-u
Narzędzia SOAP: Visual Studio, Eclipse z dodatkami
Narzędzia REST: przeglądarka, Postman, curl

W 2010 roku Twitter przeszedł z SOAP na REST i odnotował 3-krotny spadek ruchu sieciowego przy tej samej funkcjonalności.

Wskazówka: Możesz przetestować każde REST API bezpośrednio w przeglądarce wpisując https://jsonplaceholder.typicode.com/users — otrzymasz JSON-a z listą użytkowników.

Podsumowanie:

REST to sześć prostych zasad, które czynią API przewidywalnymi i skalowalnymi
Bezstanowość oznacza, że każde zapytanie musi być kompletne
REST wygrał przez prostotę — działa na standardowym HTTP i JSON-ie
Współczesne aplikacje (React, mobile, mikrousługi) bazują na REST API
Możesz testować REST w przeglądarce, podczas gdy SOAP wymaga specjalistycznych narzędzi