Autor Zpráva
Jan99
Profil *
Čau můžete mi prosím někdo vysvětlit co je SOAP, respektive v čem jsou výhody např. oproti běžnému GET/POST požadavku?

To že SOAP posílá/přijímá data přes XML formát vím ale nějak nechápu v čem je to lepší oproti běžným postupům např posílat/přijímat data přes JSON formát nebo jakkoliv jinak.

Zajímaly by mě důvody k čemu je to dobré používat a proč oproti běžným GET/POST požadavkům s parametry nebo jiným strukturovanými daty typu JSON.
nightfish
Profil
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.
quatzael
Profil
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áš..
Amunak
Profil
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.

Vaše odpověď

Mohlo by se hodit


Prosím používejte diakritiku a interpunkci.

Ochrana proti spamu. Napište prosím číslo dvě-sta čtyřicet-sedm: