REST vs. GraphQL v roce 2026: co zvolit pro vaši aplikaci

Když se navrhuje backend nové aplikace, dřív nebo později padne otázka: REST, nebo GraphQL? Odpověď z praxe je méně dramatická, než by napovídaly internetové flame wars: většině projektů stačí dobře navržený REST. GraphQL se vyplatí tam, kde máte komplexní datový model a více různých klientů. Pojďme si to rozebrat věcně.

Základní principy

REST organizuje API kolem zdrojů (resources). Každý zdroj má svou URL a pracuje se s ním standardními HTTP metodami:

GET    /api/customers        → seznam zákazníků
GET    /api/customers/42     → detail zákazníka 42
POST   /api/customers        → vytvoření zákazníka
PUT    /api/customers/42     → úprava zákazníka
DELETE /api/customers/42     → smazání zákazníka

GraphQL vystavuje jediný endpoint a klient si dotazem řekne přesně o data, která potřebuje:

query {
  customer(id: 42) {
    name
    email
    orders(last: 5) {
      number
      total
    }
  }
}

Rozdíl v filozofii: u REST určuje tvar odpovědi server, u GraphQL klient.

Overfetching a underfetching prakticky

Hlavní argument pro GraphQL se jmenuje overfetching/underfetching. Co to znamená v praxi?

Overfetching: endpoint /api/customers/42 vrací celý objekt zákazníka — 40 polí včetně fakturační adresy a historie souhlasů. Mobilní aplikace ale na obrazovce potřebuje jen jméno a e-mail. Přenášíte zbytečná data, na pomalém mobilním připojení to znát je.

Underfetching: obrazovka detailu objednávky potřebuje objednávku, zákazníka a stav dopravy. S REST to znamená tři požadavky za sebou; s GraphQL jeden dotaz.

Zní to jako jasná výhra GraphQL — jenže REST má na obojí léty prověřené odpovědi: parametr ?fields=name,email pro výběr polí, kompozitní endpointy typu /api/orders/42/summary šité na konkrétní obrazovku, nebo ?include=customer,shipping. Není to tak elegantní, ale funguje to a nese to výrazně méně infrastruktury.

Kde REST vyhrává

• Jednoduchost a rychlost vývoje. REST endpoint napíšete a otestujete za zlomek času. Žádné schéma, resolvery, žádná specializovaná knihovna na klientu.
• HTTP cache zadarmo. GET /api/products se cachuje na CDN, v prohlížeči i na reverse proxy bez jediného řádku kódu. GraphQL POSTuje na jeden endpoint — cachování musíte řešit sami.
• Veřejná API a integrace. Když vaše API konzumují třetí strany, REST je lingua franca. Účetní systémy, platební brány, dopravci — všichni mluví REST.
• Ladění a monitoring. Chybu v REST vidíte v access logu na první pohled (404 na konkrétní URL). U GraphQL je každý požadavek POST na /graphql a musíte logovat hlouběji.

Kde GraphQL vyhrává

• Více klientů s různými potřebami. Web chce plná data, mobilní aplikace minimum, partnerský portál něco mezi. S GraphQL si každý klient řekne o své — nemusíte udržovat tři sady endpointů.
• Komplexní, propojený datový model. Sociální funkce, stromové struktury, dashboardy skládající data z mnoha entit. Tam, kde by REST znamenal kaskádu požadavků, GraphQL pošle jeden dotaz.
• Rychle se měnící frontend. Produktový tým iteruje obrazovky každý týden? S GraphQL si frontend změní dotaz sám a backend se nemusí dotýkat.
• Silné typování schématu. GraphQL schéma je strojově čitelný kontrakt — generují se z něj typy pro TypeScript, dokumentace i mock data.

Náklady na údržbu, o kterých se nemluví

GraphQL není zadarmo, i když je open source:

1. N+1 problém. Naivní resolver udělá pro seznam 100 objednávek 101 dotazů do databáze. Řešení (dataloadery, batching) je potřeba umět.
2. Bezpečnost dotazů. Klient může poslat zanořený dotaz, který položí databázi. Musíte řešit limity hloubky, složitosti a rate limiting na úrovni dotazů.
3. Autorizace na úrovni polí. U REST chráníte endpointy; u GraphQL musíte hlídat, kdo smí číst které pole kterého typu. To je řádově víc práce.
4. Verzování. REST řeší verze cestou /api/v2/.... GraphQL sází na evoluci schématu (deprecated pole) — funguje, ale vyžaduje disciplínu.

U menšího týmu tyhle položky snadno spolknou úsporu, kterou GraphQL přinesl na klientovi.

Rozhodovací tabulka

Kritérium	REST	GraphQL
Jednoduchý CRUD (rezervace, e-shop, interní systém)	✅ jasná volba	zbytečná režie
Jeden webový klient	✅	zbytečná režie
Mobilní aplikace + web + partneři	funguje s kompozitními endpointy	✅ silná stránka
Komplexní propojená data (dashboardy, sociální funkce)	kaskády požadavků	✅ jeden dotaz
Veřejné API pro třetí strany	✅ standard	výjimečně
Cachování na CDN	✅ zadarmo	nutná vlastní vrstva
Malý tým, rychlé dodání	✅	vyšší vstupní náklad

Náš pohled z praxe

Ve většině projektů, které stavíme — rezervační systémy, interní aplikace, e-shopy, CRM — volíme dobře navržený REST: konzistentní pojmenování, stránkování, filtrování, kompozitní endpointy pro mobilní obrazovky. Je to nejlevnější cesta k udržovatelnému backendu a klient za API nedoplácí složitostí, kterou nevyužije. Jak přemýšlíme o návrhu API jako základu celé aplikace, popisujeme v článku o API-first přístupu.

GraphQL sáhneme tehdy, když projekt splňuje aspoň dvě kritéria z pravého sloupce tabulky — typicky produkt s mobilní aplikací, webem a administrací nad bohatým datovým modelem. A i pak často hybridně: GraphQL pro interní klienty, REST pro veřejné integrace.

Technologická volba je vždy podřízená byznysu, ne naopak — stejný princip, jaký doporučujeme při výběru technologie pro webovou aplikaci.

Shrnutí

• REST je výchozí volba: levnější na vývoj i údržbu, cache zadarmo, standard pro integrace.
• GraphQL se vyplatí u více klientů nad komplexním datovým modelem — a nese vlastní provozní náklady (N+1, bezpečnost dotazů, autorizace polí).
• Špatně navržený REST nespasí GraphQL a naopak. Kvalita návrhu API rozhoduje víc než zvolená technologie.

Řešíte backend pro svou aplikaci? Nabízíme vývoj backendu a API za měsíční paušál. Spočítejte si cenu v konfigurátoru, nebo proberte svůj datový model s námi na konzultaci — doporučíme přístup, který odpovídá vašemu projektu, ne módě.