REST vs. SOAP: rozdíly a využití při systémové integraci

REST a SOAP

REST a SOAP představují dva dominantní přístupy k návrhu a implementaci webových služeb. REST (Representational State Transfer) je architektonický styl orientovaný na zdroje a standardní protokoly, zatímco SOAP (Simple Object Access Protocol) je specifický protokol s přísně definovanou strukturou zpráv a rozšiřitelnými standardy. Cílem tohoto článku je systematicky porovnat REST a SOAP z hlediska principů, bezpečnosti, spolehlivosti, výkonu, nástrojů, verzování a typických scénářů použití – a poskytnout doporučení, kdy zvolit kterou technologii.

Historický kontext a motivace

SOAP vznikl na přelomu 90. let jako standardizovaný způsob vzdálených volání s důrazem na interoperabilitu podnikových systémů, transakce a smluvní rozhraní. REST byl formalizován kolem roku 2000 jako reakce na rostoucí web a potřebu jednoduchého, škálovatelného a cacheovatelného přístupu k datům. S nástupem mobilních a cloudových aplikací REST dominoval díky nízké režii, zatímco SOAP si udržel pozici v podnikových integracích vyžadujících komplexní záruky (bezpečnost, spolehlivé doručení, transakce).

Architektonické principy REST

• Orientace na zdroje: každý resource má jedinečné URI (/customers/123).
• Uniformní rozhraní: standardní metody HTTP (GET, POST, PUT, PATCH, DELETE), stavové kódy a hlavičky.
• Bezstavovost (stateless): každý požadavek nese vše potřebné; server neudržuje stav relace (mimo cache/ETag apod.).
• Cacheovatelnost: Cache-Control, ETag, Last-Modified umožňují horizontální škálování a snížení latence.
• Reprezentace: typicky JSON, ale také XML, HAL, JSON:API; volba prostřednictvím content negotiation.

Architektonické principy SOAP

• Protokol a obálka: každá zpráva je XML obálka s Header a Body, často přes HTTP(S), ale také SMTP či JMS.
• Smluvní rozhraní: kontrakt je definován ve WSDL (Web Services Description Language), strojově čitelném schématu operací, typů a vazeb.
• Rozšiřitelnost: standardy WS-* (WS-Security, WS-Policy, WS-Addressing, WS-ReliableMessaging, WS-AtomicTransaction) pro pokročilé požadavky.
• RPC i dokumentový styl: podpora volání ve stylu RPC i výměny dokumentů; validace XSD.

Formáty dat a reprezentace

• REST: JSON dominuje díky kompaktnosti a přímé mapovatelnosti do jazykových struktur; možné jsou také XML/YAML/CSV. Hypermediální formáty (HAL, JSON:API) přidávají odkazy a vztahy.
• SOAP: vždy XML podle XSD; přenos binárních dat přes MTOM/XOP; striktní typová kompatibilita a validace.

Adresace a operace

• REST: operace vyjadřují záměr prostřednictvím metody HTTP; URI identifikuje zdroj, nikoli akci. Idempotence (PUT, DELETE) a bezpečnost (GET) jsou důležité pro správné fungování cache a proxy.
• SOAP: operace jsou definovány kontraktem (WSDL portType/operation); endpoint je obvykle jediný a metoda je součástí zprávy (soapAction).

Bezpečnost

• REST: zabezpečení přenosu prostřednictvím TLS (HTTPS), autentizace a autorizace prostřednictvím OAuth 2.0/OIDC, mTLS, klíčů API a HTTP podpisů. Ochranu proti replay a podpisy zpráv lze řešit na aplikační vrstvě (JWS/JWT).
• SOAP: WS-Security standardizuje podpisy, šifrování a tokeny na úrovni zprávy (nezávisle na transportu), časová razítka a nonce, SAML assertion pro federaci identit. Jemnozrnná politika prostřednictvím WS-Policy.

Spolehlivost, doručování a transakce

• REST: spoléhá na HTTP; idempotence a možnost opakování požadavků zvyšují odolnost. Distribuované transakce se řeší pomocí ság, kompenzačních akcí (compensation) a eventual consistency.
• SOAP: WS-ReliableMessaging poskytuje záruky doručení (at-least-once/exactly-once) a pořadí zpráv; WS-AtomicTransaction koordinuje dvoufázové potvrzení (2PC) v omezených scénářích.

Chybové kódy a diagnostika

• REST: využívá nativní kódy HTTP (200/201/204, 400/401/403/404/409, 429, 5xx) a strukturované chybové payloady (např. type, title, detail, traceId).
• SOAP: element Fault s položkami faultcode, faultstring, detail; mapování na kódy HTTP není povinné (často se vždy vrací 200 s chybou uvnitř obálky).

Verzování a vývoj rozhraní

• REST: verzování URI (/v1) nebo typu média (application/vnd.example+json;version=2), řízená kompatibilita (přidávání volitelných polí, zachování kontraktu), hlavičky deprecation.
• SOAP: verze/změny typů ve WSDL a XSD; generované klienty je nutné znovu vygenerovat; zpětná kompatibilita prostřednictvím rozšiřitelného schématu.

Výkon, latence a cache

• REST: menší režie, kompaktní JSON, široké využití CDN a HTTP cache; ETag/If-None-Match snižují objem přenosů. Podpora komprese gzip/br a stránkování.
• SOAP: rozsáhlé XML a validace schématu zvyšují latenci; MTOM pro binární data; vhodné pro menší počet sémanticky bohatých volání.

Streaming a velké objemy dat

• REST: přenos HTTP typu chunked, požadavky range, SSE/WebSocket pro posílání dat serverem; vhodné pro oznámení v reálném čase a datové toky.
• SOAP: optimalizace prostřednictvím MTOM; zasílání zpráv přes JMS pro asynchronní zpracování.

Nástroje, ekosystém a dokumentace

• REST: OpenAPI/Swagger, JSON Schema, Postman, Insomnia, API gatewaye (omezení počtu požadavků, autentizace, monetizace), snadná integrace do moderních frontendových a backendových rámců.
• SOAP: přístup WSDL-first, šablony a generátory klientů/serverů (JAX-WS, .NET WCF), podnikové ESB a registry služeb (UDDI – historicky).

Testování, kvalita a observabilita

• REST: kontraktní testy proti OpenAPI, simulace, chaos testy, korelace prostřednictvím traceId/spanId (distribuované trasování), metriky (latence, p95, p99), kontrakty consumer-driven.
• SOAP: validační testy proti WSDL/XSD, testovací nástroje (SoapUI), důkladná validace schématu, monitorování hlaviček a zásad WS-*.

Bezpečnostní modely v praxi

• Příklady REST: OAuth 2.0 s OIDC (autentizace uživatele), client credentials pro komunikaci stroj–stroj, mTLS pro B2B; podpisy JWS a šifrování JWE u citlivých payloadů.
• Příklady SOAP: tokeny SAML ve WS-Security, šifrované a podepsané hlavičky, výměna tokenů (token exchange) prostřednictvím STS; jemně odstupňované zásady podle WS-Policy (povinné algoritmy, tolerance časových razítek).

Typické scénáře použití

• REST je vhodný pro: veřejná API, mobilní a SPA aplikace, IoT, mikroslužby, datově orientované operace CRUD, integrace s CDN.
• SOAP je vhodný pro: B2B integrace s požadavky na spolehlivé doručování, bankovnictví/pojišťovnictví, legacy ESB, scénáře s formálními kontrakty, výměnu dokumentů a transakce.

Modelování API: zdroje vs. operace

• REST: pečlivý návrh zdrojů, vztahů a reprezentací; HATEOAS (volitelně) pro navigaci; filtrování, třídění, stránkování a výběr atributů.
• SOAP: definice operací a typů; silně typované vstupy/výstupy; validace proti XSD jako první linie kontroly kvality.

Limity, kompromisy a anti-patterny

• Anti-patterny REST: akce v URI (/createUser), nadměrné používání POST místo PUT/PATCH, ignorování stavových kódů, chybějící ETag.
• Anti-patterny SOAP: přehnaně složitá schémata a zásady WS-*, ignorování chybových zpráv, neadekvátní mapování chyb na HTTP, kombinace s nestandardními transporty bez důvodu.

Srovnávací tabulka

Doporučení pro výběr

• Zvolte REST, pokud potřebujete rychlou integraci, nízkou latenci, širokou podporu klientů, cacheovatelnost, škálovatelnost a veřejně přístupné API s OAuth 2.0.
• Zvolte SOAP, pokud požadujete standardizované podpisy/šifrování zpráv na úrovni obsahu, formální kontrakt s přísnou validací, spolehlivé doručování a transakční scénáře – typicky v regulovaných odvětvích a heterogenních podnikových prostředích.
• Zvažte hybridní přístup: REST pro čtení/CRUD a události, SOAP pro kritické transakce a B2B kontrakty; případně gRPC/GraphQL pro specifické potřeby (výkonné binární protokoly, selektivní dotazy).

Osvědčené postupy při implementaci

• Konzistence: standardizujte pojmenování, chybové kódy, stránkování a filtrování.
• Bezpečnost již při návrhu: minimální rozsah tokenů, rotace klíčů, rate limiting, ochrana proti replay a injection.
• Observabilita: korelační identifikátory, strukturované logy, metriky a trasování.
• Plánování verzování: zásady ukončování podpory (deprecation policy), komunikace s konzumenty, migrační okna.
• Testy a kontrakty: automatizace validace proti OpenAPI/WSDL, testy consumer-driven.

Praktické příklady vhodného mapování

• REST CRUD: GET /orders, POST /orders, GET /orders/{id}, PATCH /orders/{id}, DELETE /orders/{id}.
• Operace SOAP: SubmitOrder, CancelOrder, GetOrderStatus s validací proti XSD a podpisem WS-Security.

Závěr

REST a SOAP nejsou nástroje, které si navzájem konkurují v rámci hry s nulovým součtem, ale slouží k řešení různých typů integračních problémů. REST vyniká jednoduchostí, výkonem a přirozeným využitím webové infrastruktury. SOAP poskytuje robustní rámec pro přísné požadavky na bezpečnost a spolehlivost s formálním kontraktem. Správná volba vychází z potřeb dané domény: požadovaných záruk, regulačních požadavků, ekosystému partnerů a dovedností týmu. V praxi se často uplatňuje kombinace – REST pro škálovatelné, veřejné a datově orientované služby, SOAP pro kritické B2B transakce a legacy integrace.