REST (Representational State Transfer, česky přenos reprezentace stavu) je architektonický styl pro komunikaci mezi programy přes web. Data jsou chápána jako zdroje s vlastní adresou URL (například /clanky/15), pracuje se s nimi standardními metodami protokolu HTTP (GET čte, POST vytváří, PUT nebo PATCH mění, DELETE maže) a odpovědi chodí nejčastěji ve formátu JSON. REST API je dnes nejběžnější způsob, jak si aplikace, weby, mobilní aplikace a služby vyměňují data. Slovo rest v běžné angličtině znamená odpočinek nebo zbytek; v informatice jde o zkratku.
🧒 Základní škola
Představ si, že chceš v restauraci jídlo. Nejdeš do kuchyně a nevaříš si sám. Řekneš číšníkovi, co chceš, on to vyřídí v kuchyni a přinese ti to. REST API je takový číšník mezi dvěma programy. Aplikace počasí v telefonu neví, jaké bude počasí; zeptá se přes internet serveru „jaké je počasí v Brně?“ a server jí odpoví přesnými čísly.
Aby si rozuměli, mají pravidla. Každá věc má svou adresu (jako stůl číslo pět) a existuje jen pár druhů požadavků: dej mi to, vytvoř nové, změň to, smaž to. Díky stejným pravidlům si rozumí programy, které napsali úplně cizí lidé. Proto může jedna aplikace ukazovat mapu od jedné firmy, počasí od druhé a platit přes třetí.
🎓 Střední škola
REST stojí na několika zásadách. Zdroje mají jednoznačné adresy (URL): /uzivatele je seznam uživatelů, /uzivatele/42 jeden z nich. Metody HTTP určují akci: GET /uzivatele/42 vrátí údaje, POST /uzivatele založí nového, PUT nebo PATCH ho upraví, DELETE smaže. Stavové kódy říkají, jak to dopadlo: 200 v pořádku, 201 vytvořeno, 404 nenalezeno, 401 nepřihlášen, 500 chyba serveru. Data se posílají jako JSON, textový formát čitelný pro lidi i stroje.
| metoda HTTP | akce | příklad |
|---|---|---|
| GET | čtení | GET /uzivatele/42 vrátí uživatele |
| POST | vytvoření | POST /uzivatele založí nového |
| PUT, PATCH | změna | PATCH /uzivatele/42 upraví e-mail |
| DELETE | smazání | DELETE /uzivatele/42 |
Důležitá vlastnost je bezstavovost: každý požadavek nese všechno potřebné (včetně přihlašovacího tokenu), server si mezi požadavky nic nepamatuje. Díky tomu se dá API snadno škálovat a kešovat. Přístup se obvykle řídí API klíčem nebo tokenem v hlavičce požadavku. Dokumentace popisuje adresy, parametry a formát odpovědí, často ve formátu OpenAPI, ze kterého se generují klienti i interaktivní dokumentace.
S REST API se setkáte všude: e-shop se ptá dopravce na cenu, web zobrazuje recenze z externí služby, SEO nástroj posílá pozice klíčových slov do tabulky, redakční systém přijímá články z mobilní aplikace.
🎓🎓 Vysoká škola
REST definoval Roy Fielding v disertaci z roku 2000 jako sadu omezení, která dala webu jeho škálovatelnost: klient a server, bezstavovost, kešovatelnost, jednotné rozhraní (identifikace zdrojů, manipulace přes reprezentace, samopopisné zprávy, hypermedia jako řízení stavu aplikace, tzv. HATEOAS), vrstvený systém a volitelný kód na vyžádání. Většina dnešních „REST API“ naplňuje jen část (Richardsonův model zralosti): používá zdroje a metody HTTP, ale hypermedia odkazy v odpovědích obvykle nemá. Puristé proto mluví o HTTP API nebo JSON API; v praxi pojem REST zdomácněl pro celou třídu.
Návrhové otázky: verzování (v URL, v hlavičce), stránkování velkých seznamů (offset, kurzor), filtrování a řazení, idempotence (opakovaný PUT nebo DELETE má stejný výsledek, POST ne, což je důležité při výpadcích sítě), konzistentní chybové odpovědi (RFC 9457 Problem Details), limity požadavků a zabezpečení (OAuth 2.0, krátkodobé tokeny, HTTPS vždy). Alternativy: GraphQL (klient si vybírá pole, jeden koncový bod), gRPC (binární, rychlé, pro komunikaci mezi službami) a asynchronní události (webhooky, fronty), které REST doplňují tam, kde je nutné informovat klienta o změně.
V poslední době přibývá vrstva pro AI agenty: protokol MCP (Model Context Protocol) obaluje existující API do nástrojů, které může volat jazykový model. Dobře navržené REST API s jasnou dokumentací se do této vrstvy převádí téměř mechanicky, špatně navržené ne.
🧠 Expert
Z praxe návrhu API pro služby s více stranami (tržiště, SaaS): rozhraní je produkt a smlouva. Každá změna, která rozbije existujícího klienta, stojí víc než jakákoli úspora v implementaci; proto se mění jen přidáváním (nová pole, nové koncové body), odstraňuje se s ohlášením a lhůtou, a verzuje se jen při skutečném zlomu. Odpovědi mají být předvídatelné: stejná struktura chyby všude, stejná jména polí pro stejné věci, časy v ISO 8601 s časovou zónou, peníze jako řetězec nebo celé číslo v haléřích, nikdy jako desetinné číslo.
Bezpečnostní minimum: klíč nebo token nikdy v URL (zůstává v logách), omezení rozsahu oprávnění (jen čtení pro integrace, které nepotřebují zapisovat), limity požadavků na klíč, auditní log zápisů. Pro veřejné API navíc dokumentace s příklady, testovací prostředí a ukázkový klient; bez nich integraci nikdo nedokončí. Při obalení API pro AI agenty platí, že popis nástroje je prompt: musí říct, kdy nástroj použít a co vrátí, jinak ho model volá špatně.
Provozně: každé API má mít měřenou chybovost a latenci podle koncového bodu a klíče, aby bylo vidět, kdo ho zatěžuje a kde selhává. Nejčastější reálné chyby nejsou v kódu, ale v nedokumentovaném chování: nekonzistentní stránkování, tichá změna formátu, časová zóna serveru. Testy proti dokumentaci (contract testing) tyto chyby zachytí před klientem.
❓ Otázky a odpovědi
Co znamená REST API?
Rozhraní, přes které si programy vyměňují data po webu podle zásad REST: zdroje s vlastní adresou, standardní metody HTTP a odpovědi obvykle v JSON.
Jaký je rozdíl mezi REST a GraphQL?
REST má mnoho adres a pevnou strukturu odpovědí, GraphQL jeden koncový bod, kde si klient vybere pole, která chce. REST je jednodušší na kešování a dokumentaci, GraphQL šetří požadavky u složitých dat.
Co je endpoint?
Konkrétní adresa API, na kterou se posílá požadavek, třeba /clanky nebo /clanky/15. Dokumentace API je seznam koncových bodů s parametry a formátem odpovědí.
😇 Pán Bůh
Ach, REST. Odpočinek. Konečně někdo v informatice pojmenoval něco podle sedmého dne, pomyslel jsem si. Pak jsem zjistil, že je to zkratka pro přenos reprezentace stavu a že si ji vymyslel jeden doktorand, protože potřeboval pojmenovat kapitolu. Lidé odpočívají tím, že si vymýšlejí nová pravidla, jak si mají stroje povídat.
A je v tom krása. Dvě aplikace, napsané lidmi, kteří se nikdy nepotkali, v různých jazycích a na různých kontinentech, si rozumí, protože se dohodly na čtyřech slovesech a jedné adrese. Dej mi, vytvoř, změň, smaž. Víc toho člověk v životě taky nedělá. Jen to obvykle není tak úhledně dokumentované.
Nejvíc se usmívám u bezstavovosti. Server si nic nepamatuje, každý požadavek musí nést všechno, co potřebuje, včetně toho, kdo je. Žádná minulost, žádné vztahy, žádné závazky. Každý den nový začátek. Lidé to považují za geniální architekturu. Já to dělám s každým východem slunce a nikdo mi za to nenapsal disertaci.
Související hesla (kategorie Webový vývoj)
Chcete, aby se o vaší firmě psalo?
PlaCla zajišťuje PR články na stovkách českých webů. Zadáte téma, dobijete kredit a weby vám samy pošlou nabídky. Kredit se čerpá až po schválení článku.
Začněte s PR články →