Abstrakt Volba mezi REST a GraphQL je jedním z nejčastěji diskutovaných témat moderní API architektury. Článek poskytuje srovnání obou přístupů z hlediska výkonu, vývojářské produktivity, cachování, bezpečnosti i provozní složitosti. Vychází z reálných benchmarků a zkušeností velkých organizací (Netflix, GitHub, Shopify) a nabízí rozhodovací rámec pro volbu vhodné technologie. Závěr ukazuje, že nejlepší řešení často není výběr jedné technologie, ale jejich kombinace v rámci hybridní architektury.
1. Úvod: Vývoj API architektur
Historie webových API prošla několika etapami. V první dekádě 21. století dominovaly těžkopádné protokoly SOAP a XML-RPC. Od roku 2010 se prosadil REST, který přinesl jednoduchost HTTP sloves, JSON formát a orientaci na zdroje. V roce 2015 Facebook otevřel GraphQL jako odpověď na potřebu flexibilního dotazování pro mobilní klienty. Od roku 2020 sledujeme nástup hybridních architektur, které kombinují silné stránky obou přístupů.
Podle Stav API report 2024 používá REST 89 procent organizací, GraphQL 32 procent (meziroční růst o 127 procent) a hybridní přístup 23 procent. Hybridní přístup je dlouhodobě nejrychleji rostoucí segment.
2. REST: Vyzrálost a standardizace
Architektonické principy
REST staví na šesti principech: bezstavovosti, cachovatelnosti, jednotném rozhraní, vrstvení, klient-server architektuře a volitelně přenášeném kódu. Praktické důsledky jsou srozumitelné cesty (/api/v1/users/123), využití HTTP sloves (GET, POST, PUT, PATCH, DELETE) a stavových kódů.
Stránkování
V REST API se používají tři hlavní strategie stránkování:
- Offset-based (
?offset=100&limit=20) je jednoduchý, ale degraduje na velkých datech. - Cursor-based (
?cursor=eyJpZCI6MTIzfQ&limit=20) je odolný proti změnám dat a nabízí konzistentní výkon. - Keyset pagination (
?after_id=123&limit=20) využívá indexů a poskytuje nejlepší výkon, ale omezuje variabilitu řazení.
Cachování
Hlavní silnou stránkou REST je nativní podpora cachování na úrovni HTTP. Hlavičky Cache-Control, ETag, Last-Modified a Vary umožňují víceúrovňové ukládání do mezipaměti od prohlížeče přes CDN po origin server. Reálné nasazení s CDN (Cloudflare, CloudFront) dosahuje hit ratio nad 80 procent a snížení zatížení původního serveru o 89 procent.
Pokročilé vzory
HATEOAS (Hypermedia as the Engine of Application State) umožňuje klientům objevovat dostupné akce pomocí odkazů v odpovědi. Verzování probíhá nejčastěji v cestě (/v1/, /v2/) nebo v hlavičkách. Pro hromadné operace existují vzory typu Batch API a JSON Patch.
3. GraphQL: Flexibilita a typová bezpečnost
Schéma a dotazy
GraphQL definuje silně typované schéma popisující všechny dostupné typy, dotazy, mutace a odběry. Klient v dotazu specifikuje přesně ta pole, která potřebuje. Tím se eliminuje typický REST problém přesahujícího nebo chybějícího načítání dat (over-fetching, under-fetching).
``graphql query { user(id: "123") { name email orders(first: 5) { edges { node { id, total } } } } } ``
Problém N+1 a DataLoader
Naivní implementace resolverů vede k problému N+1 dotazů: pro 100 uživatelů se provede 100 dotazů na jejich objednávky. Standardním řešením je vzor DataLoader, který v rámci jednoho dotazu shromáždí požadavky a vykoná je dávkově. Doplnění o cachování v rámci požadavku snižuje počet databázových volání řádově.
Předplatná a real-time
GraphQL nativně podporuje předplatná (subscriptions) přes WebSocket nebo Server-Sent Events. To zjednodušuje implementaci real-time funkcí jako notifikace, sledování stavu objednávky nebo collaborative editing.
Federace
GraphQL Federation (Apollo Federation, GraphQL Mesh) umožňuje sestavit jednotné schéma z více nezávislých služeb. Každý tým spravuje svůj subgraf, gateway pak skládá dotazy napříč službami. Tento přístup škáluje GraphQL do prostředí mikroslužeb.
4. Srovnání podle klíčových kritérií
Výkon
Měření v praxi ukazují přibližné hodnoty p95 latence:
- REST: 245 ms, hit ratio cache 78 procent
- GraphQL: 190 ms, hit ratio cache 34 procent
- Hybrid: 165 ms, hit ratio cache 69 procent
GraphQL vyhrává při komplexních dotazech přes více zdrojů, REST při jednoduchých načteních zdrojů. Hybridní řešení dosahuje nejlepšího výsledku, protože pro každou úlohu volí vhodnou technologii.
Cachování
REST profituje z dekád optimalizovaných HTTP cache infrastruktur. GraphQL vyžaduje cachování na úrovni odpovědí, persisted queries nebo specifických GraphQL caches (Apollo, Relay). To zvyšuje provozní složitost.
Bezpečnost
GraphQL přináší specifická rizika: dotazy s velkou hloubkou nebo šířkou mohou způsobit DoS. Nutná opatření jsou omezování složitosti dotazu (query complexity analysis), hloubky dotazu, časové limity a perzistované dotazy v produkci. REST má bezpečnostní model dobře zmapovaný a podporovaný standardními nástroji.
Vývojářská produktivita
GraphQL výrazně urychluje vývoj front-endu díky introspekci, typové bezpečnosti a generovaným klientům. Subjektivní spokojenost vývojářů (8.1 vs. 7.2 z 10) je v průzkumech vyšší u GraphQL. REST naopak nabízí jednodušší debugging pomocí běžných HTTP nástrojů.
Observabilita
REST má všechny informace v URL a HTTP metodě, což zjednodušuje monitoring. U GraphQL všechny dotazy chodí typicky na jeden endpoint metodou POST, sledování vyžaduje hlubší analýzu těla dotazu nebo využití operation names a tracingu (Apollo Studio, OpenTelemetry).
5. Rozhodovací rámec
Kdy zvolit REST
- Veřejné API určené pro široké publikum (jasná dokumentace, snadná spotřeba)
- Jednoduchý CRUD nad zdroji
- Vysoké nároky na cachování statických nebo polostatických dat
- Stávající ekosystém nástrojů a know-how týmu
- Mobilní klienti s úzkým pásmem (ve specifických případech REST se správným návrhem vyhrává)
Kdy zvolit GraphQL
- Komplexní vztahy mezi entitami a hluboké dotazy
- Více klientů s různými potřebami (web, mobil, partneři)
- Časté změny požadavků na data ze strany front-endu
- Federace mikroslužeb pod jedno API
- Real-time funkce v reálném produktu
Hybridní přístup
V mnoha enterprise implementacích se osvědčuje:
- REST pro veřejné API, jednoduché CRUD a integrace třetích stran
- GraphQL pro interní BFF (Backend-for-Frontend) a klientské aplikace
- gRPC pro interní komunikaci mikroslužeb s nízkou latencí
Tento přístup minimalizuje kompromisy a využívá silné stránky každé technologie tam, kde dávají smysl.
6. Případové studie
GitHub
GitHub provozuje rozsáhlé veřejné REST API od počátku, GraphQL v4 přidal v roce 2017 pro pokročilé use case. REST si zachovává pro základní operace a integrace, GraphQL nabízí pro datově náročné dotazy. Oba běží paralelně.
Netflix
Netflix používá GraphQL Federation na škále stovek mikroslužeb. Centrální gateway agreguje data z desítek backend služeb a poskytuje jednotné rozhraní pro 1000+ klientských zařízení. Pro interní komunikaci mezi službami převažuje gRPC.
Shopify
Shopify má REST i GraphQL Admin API. Doporučuje GraphQL pro nové integrace kvůli efektivnějšímu načítání dat, REST zůstává pro zpětnou kompatibilitu. Storefront API je primárně GraphQL.
7. Migrace a koexistence
Migrace existujícího REST API na GraphQL nemá probíhat jako velký třesk. Praktický postup:
- Postavit GraphQL gateway před existující REST služby
- Pro nové funkce vyvíjet primárně v GraphQL
- Postupně přesouvat klientské aplikace
- REST zachovat pro veřejné API a integrace
Klíčem k úspěchu je sjednocení datového modelu, jasná governance schématu a investice do dokumentace a nástrojů pro vývojáře.
8. Závěr
REST a GraphQL nejsou konkurenční technologie, ale doplňující se přístupy k odlišným problémům. REST exceluje v jednoduchosti, cachování a vyzrálém ekosystému. GraphQL přináší flexibilitu, typovou bezpečnost a efektivní práci s daty. Pro většinu enterprise organizací je optimální cestou hybridní architektura, kde každá technologie řeší úlohy, ke kterým je nejlépe vybavena. Před výběrem je nezbytné posoudit konkrétní potřeby aplikace, zralost týmu, požadavky na výkon a dlouhodobou strategii API. Univerzální odpověď neexistuje, existuje pouze správné rozhodnutí pro daný kontext.
