REST API

REST API (Representational State Transfer Application Programming Interface) to sposób, w jaki dwie aplikacje rozmawiają ze sobą przez sieć. Klient (np. aplikacja w przeglądarce) i serwer wymieniają się danymi za pomocą protokołu HTTP — tego samego, który ładuje strony WWW. Każdy element danych, czyli zasób, ma swój adres (URI), a żeby coś z nim zrobić, używa się kilku standardowych poleceń HTTP: GET (pobierz), POST (utwórz), PUT i PATCH (zmień), DELETE (usuń). Komunikacja jest bezstanowa: każde żądanie zawiera wszystko, czego serwer potrzebuje, a serwer nie pamięta poprzednich żądań. Interfejs nazywamy „RESTful” tylko wtedy, gdy spełnia zasady stylu REST — samo użycie HTTP i formatu JSON tego nie wystarcza.

Czym jest REST i czym różni się od REST API?

REST to styl projektowania, opisany w 2000 r. przez Roya Fieldinga w jego pracy doktorskiej. Nie jest to ani protokół, ani gotowy standard — to zestaw zasad (ograniczeń). Gdy się je stosuje, powstają systemy, które łatwo skalować, rozwijać i które nie są ze sobą zbyt mocno powiązane. REST API to z kolei konkretny interfejs zbudowany w tym stylu, najczęściej oparty na HTTP. Różnica jest praktyczna: wiele interfejsów nazywanych „REST” w rzeczywistości łamie część zasad (np. nie są w pełni bezstanowe albo nie pokazują powiązań między zasobami). Takie interfejsy określa się czasem jako „REST-like” lub po prostu „HTTP API”.

Jakie są ograniczenia architektoniczne REST?

Fielding wskazał sześć zasad. Pięć jest obowiązkowych, jedna (kod na żądanie) jest opcjonalna:

• Klient–serwer — podział ról. Klient zajmuje się tym, co widzi użytkownik, a serwer danymi i logiką. Dzięki temu obie strony można rozwijać niezależnie.
• Bezstanowość (stateless) — serwer nie pamięta sesji między żądaniami. Każde żądanie musi nieść komplet potrzebnych danych (np. token logowania). To ułatwia rozkładanie ruchu na wiele serwerów.
• Możliwość zapisania w pamięci podręcznej (cache) — odpowiedź jasno mówi, czy wolno ją zapamiętać i na jak długo (nagłówki Cache-Control, ETag). Cache zmniejsza liczbę żądań i przyspiesza działanie.
• Jednolity interfejs (uniform interface) — spójne reguły: jak nazywać zasoby (URI), jak na nie wpływać, samoopisujące się komunikaty oraz HATEOAS, czyli odnośniki podpowiadające klientowi, co może zrobić dalej.
• System warstwowy — klient nie musi wiedzieć, czy łączy się wprost z serwerem, czy przez warstwy pośrednie (serwery proxy, bramy API, load balancery, cache).
• Kod na żądanie (code on demand) — opcjonalnie serwer może wysłać klientowi kod do uruchomienia (np. skrypt). Stosowane rzadko.

Jak działa REST API?

Wszystko opiera się na prostym cyklu: klient pyta, serwer odpowiada. Żądanie klienta zawiera:

• Metodę HTTP — mówi, co klient chce zrobić (np. pobrać, utworzyć).
• Adres zasobu (URI) — np. /api/v1/users/42; wskazuje, którego obiektu dotyczy operacja.
• Nagłówki — m.in. Authorization (token logowania) oraz Accept i Content-Type, które ustalają format danych (najczęściej application/json).
• Treść (body) — przy POST, PUT czy PATCH niesie dane zasobu, zwykle w formacie JSON.

Serwer obsługuje żądanie i odsyła odpowiedź: kod statusu HTTP, nagłówki oraz dane zasobu albo informację o błędzie. Sama nazwa „Representational State Transfer” oznacza właśnie przesyłanie reprezentacji stanu zasobu (np. dokumentu JSON), a nie bezpośredni dostęp do tego, co siedzi po stronie serwera.

Metody HTTP i idempotentność

• GET — odczyt zasobu. Bezpieczna (nie zmienia stanu) i idempotentna.
• POST — utworzenie nowego zasobu lub uruchomienie operacji. Nie jest idempotentna (każde powtórzenie tworzy kolejny zasób).
• PUT — całkowite zastąpienie zasobu pod danym adresem. Idempotentna.
• PATCH — częściowa zmiana zasobu.
• DELETE — usunięcie zasobu. Idempotentna.

Idempotentność to prosta zasada: powtórzenie tego samego żądania kilka razy daje ten sam efekt po stronie serwera co jedno wysłanie. Ma to znaczenie, gdy po błędzie sieci trzeba bezpiecznie ponowić żądanie.

Kody statusu HTTP

• 2xx — sukces (200 OK, 201 Created, 204 No Content).
• 3xx — przekierowania.
• 4xx — błędy po stronie klienta (400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 429 Too Many Requests).
• 5xx — błędy po stronie serwera (500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable).

Czym REST API różni się od SOAP i GraphQL?

SOAP to protokół, a nie styl projektowania. Wymienia komunikaty w formacie XML zapakowane w tzw. kopertę (envelope), zwykle przez HTTP, ale niezależnie od sposobu transportu. Ma rozbudowane standardy (np. WS-Security i całą rodzinę WS-*), wbudowaną obsługę transakcji i ścisły kontrakt opisujący usługę (WSDL). Płaci się za to większą złożonością. REST jest lżejszy, korzysta wprost z możliwości HTTP i najczęściej z formatu JSON.

GraphQL zwykle udostępnia jeden punkt końcowy, w którym klient sam określa, jakich dokładnie pól potrzebuje. Pozwala to uniknąć dwóch typowych dla REST problemów: pobierania zbyt wielu danych (over-fetching) i zbyt małej ich ilości (under-fetching). Z kolei REST lepiej współpracuje z cache na poziomie HTTP i ma prostsze reguły. Wybór zależy od kształtu danych, potrzeb cache i złożoności klientów.

Dlaczego REST API jest istotne dla bezpieczeństwa?

Interfejsy REST to dziś jedna z głównych powierzchni ataku — wystawiają logikę i dane aplikacji wprost do sieci. Lista OWASP API Security Top 10 opisuje najczęstsze podatności interfejsów, w tym:

• Broken Object Level Authorization (BOLA/IDOR) — serwer nie sprawdza, czy zalogowany użytkownik ma prawo do konkretnego obiektu. Wystarczy zmienić w adresie /users/42 na /users/43, by zobaczyć cudze dane. To najczęstszy i najpoważniejszy błąd w API.
• Broken Authentication — słabe lub źle wdrożone logowanie, np. niepoprawne sprawdzanie tokenów.
• Broken Function Level Authorization — dostęp do operacji administracyjnych bez właściwych uprawnień.
• Nadmierna ekspozycja danych — odpowiedź zwraca więcej pól, niż klient faktycznie potrzebuje.
• Brak limitów (rate limiting) — otwiera drogę do nadużyć, masowego odpytywania i ataków typu DoS (zalewanie usługi żądaniami).

Podstawowe sposoby ochrony REST API to:

• TLS (czyli HTTPS) dla całego ruchu — szyfruje transmisję i chroni tokeny przed przechwyceniem.
• Logowanie i kontrola uprawnień — klucze API, tokeny Bearer (często w postaci JWT), a do dostępu w czyimś imieniu OAuth 2.0 z określonym zakresem uprawnień (scopes) i krótkim czasem życia tokenów.
• Sprawdzanie danych wejściowych i ścisła kontrola dostępu do każdego pojedynczego obiektu.
• Limity i spowalnianie żądań oraz obserwowanie nietypowych wzorców.

REST API z perspektywy monitorowania i wykrywania

Dla zespołu SOC i monitoringu sieci ruch REST to cenne, ale trudne źródło danych. Żądania i odpowiedzi to zwykle JSON przesyłany przez HTTPS, więc ich treść jest zaszyfrowana — wgląd uzyskuje się głównie z logów bramy lub serwera API, z metadanych (nazwa serwera SNI, czasy, ilość danych) albo z deszyfracji na serwerze proxy. Na nadużycia wskazuje kilka charakterystycznych sygnałów: nagły wzrost odpowiedzi 401/403 (ktoś próbuje obejść kontrolę dostępu), odpytywanie po kolei kolejnych identyfikatorów (enumeracja BOLA/IDOR), bardzo duża liczba wywołań z jednego źródła (scraping albo credential stuffing — masowe próby logowania skradzionymi danymi), żądania do nieudokumentowanych lub starych punktów końcowych (tzw. shadow/zombie API) oraz nietypowo duże odpowiedzi (wyciek danych). Zestawienie logów aplikacji z danymi z sieci (NetFlow/IPFIX, czyli metadane przepływów) pozwala wychwycić te wzorce nawet wtedy, gdy samej treści nie widać.

Dowiedz się więcej

• Podatność IDOR – jak wykryć atak na aplikacje webowe przez analizę ruchu HTTP — IDOR dotyczy błędów w API, gdy brak kontroli dostępu do zasobów umożliwia podgląd cudzych danych.
• Zwiększona widoczność sieci: Integracja Zabbix z Sycope w prosty sposób — Integracja Zabbix może monitorować dostępność i błędy usług wystawionych przez REST API.
• Kontrola sieci hybrydowych dzięki automatycznej inwentaryzacji zasobów, aplikacji i ich połączeń — REST API bywa jednym z analizowanych połączeń między aplikacjami w inwentaryzacji sieci.