REST vs. GraphQL API pro ecommerce integrace

Když se řeší napojení e-shopu na ERP, sklad nebo headless frontend, dřív či později padne otázka: REST, nebo GraphQL? Na konferencích to vypadá jako volba mezi starým a novým. V ecommerce praxi je to jinak. Většinou volbu udělá platforma a vy se musíte naučit s jejím API pracovat co nejlépe.

V článku ukážeme, jak se REST API a GraphQL liší v tom, co pro integraci e-shopu opravdu hraje roli: počet požadavků, rate limity, cache, chybové stavy a bezpečnost. A kdy dává smysl vlastní API postavit jedním nebo druhým způsobem.

Rozdíl v jedné minutě

REST pracuje se zdroji na pevných adresách. GET /products/123 vrátí produkt, GET /orders?status=new seznam objednávek. Každý endpoint vrací předem danou strukturu. Chcete produkt i jeho varianty a sklad? Často to znamená víc požadavků.

GraphQL má jeden endpoint a klient v dotazu popíše, která data chce. V jednom požadavku si řeknete o produkt, jen tři jeho pole, varianty a u každé varianty stav skladu. Server vrátí přesně tohle, nic navíc.

Z toho plynou dva klasické argumenty pro GraphQL: méně požadavků (odpadá tzv. under-fetching) a menší odpovědi (odpadá over-fetching). Oba jsou pravdivé. Jenže nejsou zadarmo.

Srovnání pro ecommerce integrace

Nejvíc integrací v praxi rozbije řádek „Chyby“. Integrace psaná pro REST kontroluje HTTP kód. U GraphQL může přijít odpověď 200 a v těle chyba nebo jen částečná data. Kdo to nekontroluje, zapíše do ERP neúplnou objednávku.

Co používají platformy (k 9/2026)

Shopify je nejvýraznější případ. REST Admin API je od 1. října 2024 označené jako legacy a nové funkce přibývají v GraphQL. Pro nové integrace na Shopify proto rovnou volíme GraphQL Admin API. Rate limit se tu nepočítá v požadavcích, ale v bodech za složitost dotazu. Jeden dotaz nesmí přesáhnout 1 000 bodů, kapacita se obnovuje rychlostí 50 bodů za sekundu na základních tarifech, 100 na Advanced a 500 na Shopify Plus (k 9/2026, aktuální limity ověřte v dokumentaci Shopify). Pro velké exporty má Shopify bulk operace, které běží na pozadí a do limitů se nezapočítávají.

Shoptet staví na REST. Rate limiter měří složitost požadavků (větší odpověď a náročnější filtr stojí víc), na jeden token povoluje nejvýš 3 souběžná spojení a při překročení vrací HTTP 429 s hlavičkou Retry-After (k 9/2026).

WooCommerce má REST API v3. Seznamy vrací standardně po 10 položkách, parametrem per_page nejvýš 100. Celkový počet položek a stránek najdete v hlavičkách X-WP-Total a X-WP-TotalPages. Export velkého katalogu tak znamená desítky až stovky požadavků a stojí za to je rozvrhnout.

Adobe Commerce má obě API a ve vývojářské dokumentaci jasně píše, že GraphQL je určené pro storefront a REST pro administrační integrace. To je v kostce i naše doporučení pro vlastní řešení.

Kdy dává smysl REST

• Serverové integrace s ERP, skladem a účetnictvím. Operace jsou jasně dané: stáhni objednávky, zapiš sklad, aktualizuj ceny.
• Veřejná data s cache. Katalog pro partnery nebo dostupnost pro srovnávače se dají cachovat na CDN.
• Jednoduchý provoz. Logy, monitoring a chybové stavy fungují bez zvláštního nástrojování.
• Integrace pro partnery. Dodavatel nebo dopravce REST zná. S GraphQL budete vysvětlovat.

Kdy dává smysl GraphQL

• [Headless commerce](/kb/integrace/headless-commerce). Frontend potřebuje na každé stránce jiný výřez dat. Detail produktu, výpis kategorie a košík se dají načíst jedním dotazem bez nadbytečných polí.
• Mobilní aplikace. Menší odpovědi a méně požadavků jsou znát na pomalé síti.
• Platforma, která ho vyžaduje. U Shopify je to dnes hlavní cesta.
• Složené dotazy přes víc zdrojů. GraphQL vrstva může spojit data z e-shopu, PIM a recenzí do jednoho schématu.

Bezpečnost a výkon: pasti GraphQL

Flexibilita GraphQL je i jeho riziko. OWASP v GraphQL Cheat Sheetu upozorňuje na několik míst, která v REST neřešíte:

• Hloubka a velikost dotazu. Bez limitů si klient může vyžádat produkty, u nich kategorie, u nich zase produkty a tak dál. Takový dotaz umí server položit. Limity hloubky a počtu položek je potřeba nastavit.
• Introspekce. GraphQL často umí vypsat celé schéma včetně polí, která nemají být veřejná. Na produkci ji omezte.
• Batching. Víc operací v jednom požadavku obchází běžné limity počtu požadavků. Omezte počet operací na požadavek.
• Problém N+1. Naivní implementace načítá každou variantu zvlášť z databáze. Řeší se dávkovým načítáním (například vzorem DataLoader).

Pokud GraphQL jen konzumujete (Shopify), tyto věci řeší platforma. Hlídáte si hlavně cenu svých dotazů a paginaci přes cursor. Pokud GraphQL API stavíte, jsou to vaše povinnosti. Širší kontext bezpečnosti rozebíráme v článku Bezpečnost API integrací.

Jak na to prakticky

Když navrhujeme integraci nebo vlastní API, postupujeme takto:

1. Zjistíme, co nabízí platforma. Na Shoptetu a WooCommerce REST, na Shopify GraphQL. Nebojujeme proti tomu.
2. Změříme objem. Kolik produktů, objednávek a změn denně. Podle toho volíme mezi běžnými dotazy, dávkovými exporty a webhooky.
3. Spočítáme limity. Kolik požadavků nebo bodů spotřebuje jedna synchronizace a jestli se vejde do limitu i ve špičce.
4. Ošetříme chyby. U REST HTTP kódy a 429 s čekáním, u GraphQL navíc pole errors a částečná data.
5. Pro vlastní API volíme podle klienta. Pro serverové integrace REST, pro headless frontend GraphQL. Obojí s dokumentací a verzováním.

Návrh a stavbu API děláme v rámci služby API a mikroslužby, napojení konkrétních systémů v rámci integrací. Pokud řešíte přechod Shopify integrace z REST na GraphQL, nebo nevíte, jestli se vaše synchronizace vejde do limitů, ozvěte se nám. Projdeme to na vašich datech.