{"id":4823,"date":"2026-08-11T20:59:13","date_gmt":"2026-08-11T18:59:13","guid":{"rendered":"https:\/\/www.sycope.com\/?post_type=dictionary-item&#038;p=4823"},"modified":"2026-08-11T22:47:00","modified_gmt":"2026-08-11T20:47:00","slug":"rest-api","status":"publish","type":"dictionary-item","link":"https:\/\/www.sycope.com\/pl\/post\/dictionary-item\/rest-api","title":{"rendered":"REST API"},"content":{"rendered":"<p><strong>REST <a href=\"https:\/\/www.sycope.com\/pl\/post\/dictionary-item\/api\">API<\/a><\/strong> (Representational State Transfer Application Programming Interface) to spos\u00f3b, w jaki dwie aplikacje rozmawiaj\u0105 ze sob\u0105 przez sie\u0107. Klient (np. aplikacja w przegl\u0105darce) i serwer wymieniaj\u0105 si\u0119 danymi za pomoc\u0105 protoko\u0142u HTTP \u2014 tego samego, kt\u00f3ry \u0142aduje strony WWW. Ka\u017cdy element danych, czyli <strong>zas\u00f3b<\/strong>, ma sw\u00f3j adres (URI), a \u017ceby co\u015b z nim zrobi\u0107, u\u017cywa si\u0119 kilku standardowych polece\u0144 HTTP: <code>GET<\/code> (pobierz), <code>POST<\/code> (utw\u00f3rz), <code>PUT<\/code> i <code>PATCH<\/code> (zmie\u0144), <code>DELETE<\/code> (usu\u0144). Komunikacja jest bezstanowa: ka\u017cde \u017c\u0105danie zawiera wszystko, czego serwer potrzebuje, a serwer nie pami\u0119ta poprzednich \u017c\u0105da\u0144. Interfejs nazywamy \u201eRESTful\u201d tylko wtedy, gdy spe\u0142nia zasady stylu REST \u2014 samo u\u017cycie HTTP i formatu JSON tego nie wystarcza.<\/p>\n<h2>Czym jest REST i czym r\u00f3\u017cni si\u0119 od REST API?<\/h2>\n<p><strong>REST<\/strong> to styl projektowania, opisany w 2000 r. przez Roya Fieldinga w jego pracy doktorskiej. Nie jest to ani protok\u00f3\u0142, ani gotowy standard \u2014 to zestaw zasad (ogranicze\u0144). Gdy si\u0119 je stosuje, powstaj\u0105 systemy, kt\u00f3re \u0142atwo skalowa\u0107, rozwija\u0107 i kt\u00f3re nie s\u0105 ze sob\u0105 zbyt mocno powi\u0105zane. <em>REST <a href=\"https:\/\/www.sycope.com\/pl\/post\/dictionary-item\/api\">API<\/a><\/em> to z kolei konkretny interfejs zbudowany w tym stylu, najcz\u0119\u015bciej oparty na HTTP. R\u00f3\u017cnica jest praktyczna: wiele interfejs\u00f3w nazywanych \u201eREST\u201d w rzeczywisto\u015bci \u0142amie cz\u0119\u015b\u0107 zasad (np. nie s\u0105 w pe\u0142ni bezstanowe albo nie pokazuj\u0105 powi\u0105za\u0144 mi\u0119dzy zasobami). Takie interfejsy okre\u015bla si\u0119 czasem jako \u201eREST-like\u201d lub po prostu \u201eHTTP API\u201d.<\/p>\n<h2>Jakie s\u0105 ograniczenia architektoniczne REST?<\/h2>\n<p>Fielding wskaza\u0142 sze\u015b\u0107 zasad. Pi\u0119\u0107 jest obowi\u0105zkowych, jedna (kod na \u017c\u0105danie) jest opcjonalna:<\/p>\n<ul>\n<li><strong>Klient\u2013serwer<\/strong> \u2014 podzia\u0142 r\u00f3l. Klient zajmuje si\u0119 tym, co widzi u\u017cytkownik, a serwer danymi i logik\u0105. Dzi\u0119ki temu obie strony mo\u017cna rozwija\u0107 niezale\u017cnie.<\/li>\n<li><strong>Bezstanowo\u015b\u0107 (stateless)<\/strong> \u2014 serwer nie pami\u0119ta sesji mi\u0119dzy \u017c\u0105daniami. Ka\u017cde \u017c\u0105danie musi nie\u015b\u0107 komplet potrzebnych danych (np. token logowania). To u\u0142atwia rozk\u0142adanie ruchu na wiele serwer\u00f3w.<\/li>\n<li><strong>Mo\u017cliwo\u015b\u0107 zapisania w pami\u0119ci podr\u0119cznej (cache)<\/strong> \u2014 odpowied\u017a jasno m\u00f3wi, czy wolno j\u0105 zapami\u0119ta\u0107 i na jak d\u0142ugo (nag\u0142\u00f3wki <code>Cache-Control<\/code>, <code>ETag<\/code>). Cache zmniejsza liczb\u0119 \u017c\u0105da\u0144 i przyspiesza dzia\u0142anie.<\/li>\n<li><strong>Jednolity interfejs (uniform interface)<\/strong> \u2014 sp\u00f3jne regu\u0142y: jak nazywa\u0107 zasoby (URI), jak na nie wp\u0142ywa\u0107, samoopisuj\u0105ce si\u0119 komunikaty oraz HATEOAS, czyli odno\u015bniki podpowiadaj\u0105ce klientowi, co mo\u017ce zrobi\u0107 dalej.<\/li>\n<li><strong>System warstwowy<\/strong> \u2014 klient nie musi wiedzie\u0107, czy \u0142\u0105czy si\u0119 wprost z serwerem, czy przez warstwy po\u015brednie (serwery proxy, bramy API, load balancery, cache).<\/li>\n<li><strong>Kod na \u017c\u0105danie (code on demand)<\/strong> \u2014 opcjonalnie serwer mo\u017ce wys\u0142a\u0107 klientowi kod do uruchomienia (np. skrypt). Stosowane rzadko.<\/li>\n<\/ul>\n<h2>Jak dzia\u0142a REST API?<\/h2>\n<p>Wszystko opiera si\u0119 na prostym cyklu: klient pyta, serwer odpowiada. \u017b\u0105danie klienta zawiera:<\/p>\n<ul>\n<li><strong>Metod\u0119 HTTP<\/strong> \u2014 m\u00f3wi, co klient chce zrobi\u0107 (np. pobra\u0107, utworzy\u0107).<\/li>\n<li><strong>Adres zasobu (URI)<\/strong> \u2014 np. <code>\/api\/v1\/users\/42<\/code>; wskazuje, kt\u00f3rego obiektu dotyczy operacja.<\/li>\n<li><strong>Nag\u0142\u00f3wki<\/strong> \u2014 m.in. <code>Authorization<\/code> (token logowania) oraz <code>Accept<\/code> i <code>Content-Type<\/code>, kt\u00f3re ustalaj\u0105 format danych (najcz\u0119\u015bciej <code>application\/json<\/code>).<\/li>\n<li><strong>Tre\u015b\u0107 (body)<\/strong> \u2014 przy <code>POST<\/code>, <code>PUT<\/code> czy <code>PATCH<\/code> niesie dane zasobu, zwykle w formacie JSON.<\/li>\n<\/ul>\n<p>Serwer obs\u0142uguje \u017c\u0105danie i odsy\u0142a odpowied\u017a: kod statusu HTTP, nag\u0142\u00f3wki oraz dane zasobu albo informacj\u0119 o b\u0142\u0119dzie. Sama nazwa \u201eRepresentational State Transfer\u201d oznacza w\u0142a\u015bnie przesy\u0142anie reprezentacji stanu zasobu (np. dokumentu JSON), a nie bezpo\u015bredni dost\u0119p do tego, co siedzi po stronie serwera.<\/p>\n<h3>Metody HTTP i idempotentno\u015b\u0107<\/h3>\n<ul>\n<li><code>GET<\/code> \u2014 odczyt zasobu. Bezpieczna (nie zmienia stanu) i idempotentna.<\/li>\n<li><code>POST<\/code> \u2014 utworzenie nowego zasobu lub uruchomienie operacji. Nie jest idempotentna (ka\u017cde powt\u00f3rzenie tworzy kolejny zas\u00f3b).<\/li>\n<li><code>PUT<\/code> \u2014 ca\u0142kowite zast\u0105pienie zasobu pod danym adresem. Idempotentna.<\/li>\n<li><code>PATCH<\/code> \u2014 cz\u0119\u015bciowa zmiana zasobu.<\/li>\n<li><code>DELETE<\/code> \u2014 usuni\u0119cie zasobu. Idempotentna.<\/li>\n<\/ul>\n<p><strong>Idempotentno\u015b\u0107<\/strong> to prosta zasada: powt\u00f3rzenie tego samego \u017c\u0105dania kilka razy daje ten sam efekt po stronie serwera co jedno wys\u0142anie. Ma to znaczenie, gdy po b\u0142\u0119dzie sieci trzeba bezpiecznie ponowi\u0107 \u017c\u0105danie.<\/p>\n<h3>Kody statusu HTTP<\/h3>\n<ul>\n<li><strong>2xx<\/strong> \u2014 sukces (<code>200 OK<\/code>, <code>201 Created<\/code>, <code>204 No Content<\/code>).<\/li>\n<li><strong>3xx<\/strong> \u2014 przekierowania.<\/li>\n<li><strong>4xx<\/strong> \u2014 b\u0142\u0119dy po stronie klienta (<code>400 Bad Request<\/code>, <code>401 Unauthorized<\/code>, <code>403 Forbidden<\/code>, <code>404 Not Found<\/code>, <code>429 Too Many Requests<\/code>).<\/li>\n<li><strong>5xx<\/strong> \u2014 b\u0142\u0119dy po stronie serwera (<code>500 Internal Server Error<\/code>, <code>502 Bad Gateway<\/code>, <code>503 Service Unavailable<\/code>).<\/li>\n<\/ul>\n<h2>Czym REST API r\u00f3\u017cni si\u0119 od SOAP i GraphQL?<\/h2>\n<p><strong>SOAP<\/strong> to protok\u00f3\u0142, a nie styl projektowania. Wymienia komunikaty w formacie XML zapakowane w tzw. kopert\u0119 (envelope), zwykle przez HTTP, ale niezale\u017cnie od sposobu transportu. Ma rozbudowane standardy (np. WS-Security i ca\u0142\u0105 rodzin\u0119 WS-*), wbudowan\u0105 obs\u0142ug\u0119 transakcji i \u015bcis\u0142y kontrakt opisuj\u0105cy us\u0142ug\u0119 (WSDL). P\u0142aci si\u0119 za to wi\u0119ksz\u0105 z\u0142o\u017cono\u015bci\u0105. REST jest l\u017cejszy, korzysta wprost z mo\u017cliwo\u015bci HTTP i najcz\u0119\u015bciej z formatu JSON.<\/p>\n<p><strong>GraphQL<\/strong> zwykle udost\u0119pnia jeden punkt ko\u0144cowy, w kt\u00f3rym klient sam okre\u015bla, jakich dok\u0142adnie p\u00f3l potrzebuje. Pozwala to unikn\u0105\u0107 dw\u00f3ch typowych dla REST problem\u00f3w: pobierania zbyt wielu danych (over-fetching) i zbyt ma\u0142ej ich ilo\u015bci (under-fetching). Z kolei REST lepiej wsp\u00f3\u0142pracuje z cache na poziomie HTTP i ma prostsze regu\u0142y. Wyb\u00f3r zale\u017cy od kszta\u0142tu danych, potrzeb cache i z\u0142o\u017cono\u015bci klient\u00f3w.<\/p>\n<h2>Dlaczego REST API jest istotne dla bezpiecze\u0144stwa?<\/h2>\n<p>Interfejsy REST to dzi\u015b jedna z g\u0142\u00f3wnych powierzchni ataku \u2014 wystawiaj\u0105 logik\u0119 i dane aplikacji wprost do sieci. Lista <strong>OWASP <a href=\"https:\/\/www.sycope.com\/pl\/post\/dictionary-item\/api-security\">API Security<\/a> Top 10<\/strong> opisuje najcz\u0119stsze podatno\u015bci interfejs\u00f3w, w tym:<\/p>\n<ul>\n<li><strong>Broken Object Level Authorization (BOLA\/IDOR)<\/strong> \u2014 serwer nie sprawdza, czy zalogowany u\u017cytkownik ma prawo do konkretnego obiektu. Wystarczy zmieni\u0107 w adresie <code>\/users\/42<\/code> na <code>\/users\/43<\/code>, by zobaczy\u0107 cudze dane. To najcz\u0119stszy i najpowa\u017cniejszy b\u0142\u0105d w API.<\/li>\n<li><strong>Broken Authentication<\/strong> \u2014 s\u0142abe lub \u017ale wdro\u017cone logowanie, np. niepoprawne sprawdzanie token\u00f3w.<\/li>\n<li><strong>Broken Function Level Authorization<\/strong> \u2014 dost\u0119p do operacji administracyjnych bez w\u0142a\u015bciwych uprawnie\u0144.<\/li>\n<li><strong>Nadmierna ekspozycja danych<\/strong> \u2014 odpowied\u017a zwraca wi\u0119cej p\u00f3l, ni\u017c klient faktycznie potrzebuje.<\/li>\n<li><strong>Brak limit\u00f3w (<a href=\"https:\/\/www.sycope.com\/pl\/post\/dictionary-item\/rate-limiting\">rate limiting<\/a>)<\/strong> \u2014 otwiera drog\u0119 do nadu\u017cy\u0107, masowego odpytywania i atak\u00f3w typu <a href=\"https:\/\/www.sycope.com\/pl\/post\/dictionary-item\/dos-denial-of-service\">DoS<\/a> (zalewanie us\u0142ugi \u017c\u0105daniami).<\/li>\n<\/ul>\n<p>Podstawowe sposoby ochrony REST API to:<\/p>\n<ul>\n<li><strong><a href=\"https:\/\/www.sycope.com\/pl\/post\/dictionary-item\/tls-ssl\">TLS<\/a><\/strong> (czyli <a href=\"https:\/\/www.sycope.com\/pl\/post\/dictionary-item\/http-https\">HTTPS<\/a>) dla ca\u0142ego ruchu \u2014 szyfruje transmisj\u0119 i chroni tokeny przed przechwyceniem.<\/li>\n<li><strong>Logowanie i kontrola uprawnie\u0144<\/strong> \u2014 klucze API, tokeny Bearer (cz\u0119sto w postaci JWT), a do dost\u0119pu w czyim\u015b imieniu <strong>OAuth 2.0<\/strong> z okre\u015blonym zakresem uprawnie\u0144 (scopes) i kr\u00f3tkim czasem \u017cycia token\u00f3w.<\/li>\n<li><strong>Sprawdzanie danych wej\u015bciowych<\/strong> i \u015bcis\u0142a kontrola dost\u0119pu do ka\u017cdego pojedynczego obiektu.<\/li>\n<li><strong>Limity i spowalnianie<\/strong> \u017c\u0105da\u0144 oraz obserwowanie nietypowych wzorc\u00f3w.<\/li>\n<\/ul>\n<h3>REST API z perspektywy monitorowania i wykrywania<\/h3>\n<p>Dla zespo\u0142u <a href=\"https:\/\/www.sycope.com\/pl\/post\/dictionary-item\/soc-security-operations-center\">SOC<\/a> i monitoringu sieci ruch REST to cenne, ale trudne \u017ar\u00f3d\u0142o danych. \u017b\u0105dania i odpowiedzi to zwykle JSON przesy\u0142any przez <a href=\"https:\/\/www.sycope.com\/pl\/post\/dictionary-item\/http-https\">HTTPS<\/a>, wi\u0119c ich tre\u015b\u0107 jest zaszyfrowana \u2014 wgl\u0105d uzyskuje si\u0119 g\u0142\u00f3wnie z log\u00f3w bramy lub serwera API, z metadanych (nazwa serwera SNI, czasy, ilo\u015b\u0107 danych) albo z deszyfracji na serwerze proxy. Na nadu\u017cycia wskazuje kilka charakterystycznych sygna\u0142\u00f3w: nag\u0142y wzrost odpowiedzi <code>401<\/code>\/<code>403<\/code> (kto\u015b pr\u00f3buje obej\u015b\u0107 kontrol\u0119 dost\u0119pu), odpytywanie po kolei kolejnych identyfikator\u00f3w (enumeracja BOLA\/IDOR), bardzo du\u017ca liczba wywo\u0142a\u0144 z jednego \u017ar\u00f3d\u0142a (scraping albo <a href=\"https:\/\/www.sycope.com\/pl\/post\/dictionary-item\/credential-stuffing\">credential stuffing<\/a> \u2014 masowe pr\u00f3by logowania skradzionymi danymi), \u017c\u0105dania do nieudokumentowanych lub starych punkt\u00f3w ko\u0144cowych (tzw. shadow\/zombie API) oraz nietypowo du\u017ce odpowiedzi (<a href=\"https:\/\/www.sycope.com\/pl\/post\/dictionary-item\/data-exfiltration-wyciek-danych\">wyciek danych<\/a>). Zestawienie log\u00f3w aplikacji z danymi z sieci (<a href=\"https:\/\/www.sycope.com\/pl\/post\/dictionary-item\/netflow\">NetFlow<\/a>\/<a href=\"https:\/\/www.sycope.com\/pl\/post\/dictionary-item\/ipfix\">IPFIX<\/a>, czyli metadane przep\u0142yw\u00f3w) pozwala wychwyci\u0107 te wzorce nawet wtedy, gdy samej tre\u015bci nie wida\u0107.<\/p>\n<h2>Dowiedz si\u0119 wi\u0119cej<\/h2>\n<ul>\n<li><a href=\"https:\/\/www.sycope.com\/pl\/post\/podatnosc-idor-jak-wykryc-atak-na-aplikacje-webowe-przez-analize-ruchu-http\">Podatno\u015b\u0107 IDOR \u2013 jak wykry\u0107 atak na aplikacje webowe przez analiz\u0119 ruchu HTTP<\/a> \u2014 IDOR dotyczy b\u0142\u0119d\u00f3w w API, gdy brak kontroli dost\u0119pu do zasob\u00f3w umo\u017cliwia podgl\u0105d cudzych danych.<\/li>\n<li><a href=\"https:\/\/www.sycope.com\/pl\/post\/enhancing-network-visibility-zabbix-integration-with-sycope-made-easy\">Zwi\u0119kszona widoczno\u015b\u0107 sieci: Integracja Zabbix z Sycope w prosty spos\u00f3b<\/a> \u2014 Integracja Zabbix mo\u017ce monitorowa\u0107 dost\u0119pno\u015b\u0107 i b\u0142\u0119dy us\u0142ug wystawionych przez REST API.<\/li>\n<li><a href=\"https:\/\/www.sycope.com\/pl\/post\/controlling-hybrid-networks-through-automatic-inventory-of-resources-applications-and-their-connections\">Kontrola sieci hybrydowych dzi\u0119ki automatycznej inwentaryzacji zasob\u00f3w, aplikacji i ich po\u0142\u0105cze\u0144<\/a> \u2014 REST API bywa jednym z analizowanych po\u0142\u0105cze\u0144 mi\u0119dzy aplikacjami w inwentaryzacji sieci.<\/li>\n<\/ul>\n","protected":false},"featured_media":0,"template":"","class_list":["post-4823","dictionary-item","type-dictionary-item","status-publish","hentry"],"acf":{"tytul":"REST API","ikona":"","krotki_opis":"Spos\u00f3b, w jaki aplikacje wymieniaj\u0105 dane przez HTTP w stylu REST: ka\u017cdy zas\u00f3b ma sw\u00f3j adres, u\u017cywa si\u0119 metod GET\/POST\/PUT\/DELETE, a serwer nie pami\u0119ta sesji."},"_links":{"self":[{"href":"https:\/\/www.sycope.com\/pl\/wp-json\/wp\/v2\/dictionary-item\/4823","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.sycope.com\/pl\/wp-json\/wp\/v2\/dictionary-item"}],"about":[{"href":"https:\/\/www.sycope.com\/pl\/wp-json\/wp\/v2\/types\/dictionary-item"}],"wp:attachment":[{"href":"https:\/\/www.sycope.com\/pl\/wp-json\/wp\/v2\/media?parent=4823"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}