REST vs. SOAP

REST a SOAP

REST a SOAP reprezentují 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 zprávovou strukturou a rozšíř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 pozice v enterprise integracích vyžadujících komplexní záruky (bezpečnost, spolehlivé doručení, transakce).

Architektonické principy REST

• Orientáce 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 session stav (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 i XML, HAL, JSON:API; volba přes 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 i SMTP či JMS.
• Smluvní rozhraní: kontrakt je definován ve WSDL (Web Services Description Language), strojově čitelné schéma 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; XML/YAML/CSV jsou rovněž možné. Hypermedia formáty (HAL, JSON:API) přidávají odkazy a vztahy.
• SOAP: vždy XML dle XSD; přenos binárních dat přes MTOM/XOP; striktní typová kompatibilita a validace.

Adresace a operace

• REST: operace vyjadřují úmysl skrze HTTP metodu; URI identifikuje zdroj, nikoli akci. Idempotence (PUT, DELETE) a bezpečnost (GET) jsou důležité pro korektní chování cache a proxy.
• SOAP: operace jsou definovány kontraktem (WSDL portType/operation); endpoint je typicky jediný a metoda je součástí zprávy (soapAction).

Bezpečnost

• REST: transportní zabezpečení přes TLS (HTTPS), autentizace a autorizace přes OAuth 2.0/OIDC, mTLS, API klíče, HTTP podpisy. Ochrana 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), timestampy a nonce, SAML assertion pro federaci identit. Jemnozrnná politika přes WS-Policy.

Spolehlivost, doručování a transakce

• REST: spoléhá na HTTP; idempotence a opakovatelnost požadavků zvyšují odolnost. Distribuované transakce se řeší sa­gami, compensation akcemi a eventual consistency.
• SOAP: WS-ReliableMessaging poskytuje garance 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: Fault element s faultcode, faultstring, detail; mapování na HTTP kódy není povinné (často vždy 200 s faultem uvnitř obálky).

Verzování a evoluce rozhraní

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

Výkon, latence a cache

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

Streaming a velké objemy dat

• REST: HTTP chunked přenos, range požadavky, SSE/WebSocket pro server push; vhodné pro real-time notifikace a datové toky.
• SOAP: optimalizace přes MTOM; messaging přes JMS pro asynchronní zpracování.

Nástroje, ekosystém a dokumentace

• REST: OpenAPI/Swagger, JSON Schema, Postman, Insomnia, API Gatewaye (rate limiting, auth, monetizace), snadná integrace v moderních FE/BE rámcích.
• SOAP: WSDL-first přístup, š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, mocking, chaos testy, korelace přes traceId/spanId (Distributed Tracing), metriky (latence, p95, p99), consumer-driven kontrakty.
• SOAP: validační testy proti WSDL/XSD, testery (SoapUI), hloubková schema-validace, monitoring WS-* hlaviček a zásad.

Bezpečnostní modely v praxi

• REST příklady: OAuth 2.0 s OIDC (autentizace uživatele), client credentials pro stroj–stroj, mTLS pro B2B; podpisy JWS a šifrování JWE u citlivých payloadů.
• SOAP příklady: SAML tokeny v WS-Security, šifrované a podepsané hlavičky, token exchange přes STS; jemné politiky dle WS-Policy (povinné algoritmy, timestamp tolerance).

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

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

Modelování API: zdroje vs. operace

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

Limity, kompromisy a anti-patterny

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

Porovnávací tabulka

Doporučení pro výběr

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

Best practices při implementaci

• Konzistence: standardizujte pojmenování, kódy chyb, stránkování a filtrování.
• Bezpečnost by design: minimální rozsah tokenů, rotace klíčů, rate limiting, ochrana proti replay a injection.
• Observabilita: korelační identifikátory, strukturované logy, metriky a tracing.
• Verzování s plánem: deprecation policy, komunikace s konzumenty, migrační okna.
• Testy a kontrakty: automatizace validace proti OpenAPI/WSDL, consumer-driven testy.

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

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

Závěr

REST a SOAP nejsou konkurenty v nultém součtu, ale nástroji pro různé druhy integračních problémů. REST exceluje jednoduchostí, výkonem a přirozeným využitím webové infrastruktury. SOAP poskytuje robustní rámec pro přísné bezpečnostní a spolehlivostní požadavky s formálním kontraktem. Správná volba vychází z doménových potřeb: požadovaných garancí, regulačních nároků, 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.