SOAP výhody, co je SOAP

V dnešní době bych se použití SOAPu vyhnul, kromě případů, kdy potřebuji komunikovat s webovou službou, která jiné než SOAP požadavky nepodporuje. SOAP vzniknul v době, kdy ještě JSON ani neexistoval a primárně byl jako alternativa k technologiím DCOM a CORBA, což jej řadí spíš do řešení "enterprise" sféry.

Jan99:
SOAP je základní podstatou webových služeb. Jestli se ptáš na výhody, tak záleží jestli jsi v roli poskytovatele webové služby nebo její uživatel. Když uživatel, tak většinou nemáš moc na výběr a musíš volit SOAP. Málo kdo poskytuje více forem komunikací.
Nevýhody mohou vzniknout tím, že je ta služba špatně navržena a například nemáš možnost zažádat o jednu konkrétní informaci, ale pomocí jedné funkce dostaneš obsáhlejší data, což činí webovou službu pomalejší. Už jsem zažil webovou službu, která posílala na jednoduchý request hromadu dat v neskutečně složitý formě. Potřeboval jsem pár hodnot a vyplivlo mi to šílenej strom o skoro deseti úrovních a v jednotlivých větvích se ta data i opakovala. Odpověď potom trvala klidně i 10 sekund, což je prakticky nepoužitelný. S normálně navrženou webovou službou se ale dostaneš běžně pod sekundu.

Na tu rychlost je asi nejlepší REST API, která využívá JSON. Tam prakticky nečekáš..

quatzael:
„Už jsem zažil webovou službu, která posílala na jednoduchý request hromadu dat v neskutečně složitý formě. Potřeboval jsem pár hodnot a vyplivlo mi to šílenej strom o skoro deseti úrovních a v jednotlivých větvích se ta data i opakovala.“
To je dané tím, že REST (a teda i SOAP a spousta podobných protokolů) je určená k předávání *objektů*. A objekty často bývají vzájemně propojené (např. objekt uživatele může odkazovat na kolekci jeho skupin, a každá skupina zase obsahuje odkaz na kolekci uživatelů, které ji mají přiřazenou).

No a protože je pro API výhodné nevracet jen ten "hlavní" objekt, ale třeba i druhou nebo vyšší úrověň zanoření (třeba při příkladu s uživatelskými skupinamy bys jinak nebyl vůbec schopný zjistit, co jsou uživatelovy skupiny zač), serializační knihovny zkrátka vrací několik úroveň zanoření. A protože si toho autor API nevšiml (nebo to ignoroval/neuměl nastavit), jeho API vracelo hlubší rekurzi objektů se spoustou zbytečných dat.

Ale tohle se ti může stát u libovolného API které vrací objekty. Já s něčím podobným nedávno taky trochu bojoval :-) Naštěstí dobrý serializer má mocné nástroje na úpravu toho, co vlastně z toho objektu (a do jaké hloubky) chceš předat jako odpověd v API, takže se to dá snadno řešit.