Názory k článku
Java na webovém serveru: SOAP webové služby

Můžete si zkusit vložit nějaký podnik s existující adresou a pak zavolat tu webovou službu http://nekurak.net/ws/ resp. http://nekurak.net/ws/podnikSluzba?Tester

Měly by se zjistit jeho souřadnice a pak by se měla v detailu (po rozkliknutí podniku) zobrazovat jeho mapa. Ale Google občas najde souřadnice i k nesmyslným adresám, takže ty mapy jsou někdy trochu mimo…

Dovolim si okomentovat casti clanku, ktore nie su podla mna vhodne napisane a bolo by lepsie, keby sa v clanku nevyskytli aby sa dalej nesirili dezinformacie. Nepojdem do detailov, ktore som uz popisal v:
http://zdrojak.root.cz/clanky/java-na-webovem-serveru-piseme-rest-api/nazory/8426/
http://zdrojak.root.cz/clanky/java-na-webovem-serveru-piseme-rest-api/nazory/8425/
http://zdrojak.root.cz/clanky/java-na-webovem-serveru-piseme-rest-api/nazory/8430/
http://zdrojak.root.cz/clanky/java-na-webovem-serveru-piseme-rest-api/nazory/8437/

> V následujícím textu budu SOAP používat jako zkratku pro webové služby postavené nad tímto protokolem (ne jen pro protokol samotný) a podobně REST pro webové služby nad ním postavené.

Pouzivat jednu skratku SOAP pre 2 rozne veci v jednom cl, co zodpoveda specofikaciamanku je podla mna nevhodne.
Ak chceme hovorit o SOAP web sluzbach je lepsie pouzit napriklad „SOAP WS“, alebo WS-*. Obdobne pre REST a REST web sluzby.
Prave takymto obskurovanim pojmov totiz dochadza k najvacsim nedorozumeniam.

> Kdy zvolit REST a kdy SOAP. Existují dvě základní kritéria, podle kterých se můžeme rozhodovat: Logický pohled …, Pragmatičtější pohled …

Obe kriteria vyzeraju logicky, ale nevychadzaju z podstaty a rozdielov WS-* a RESTu (vid. http://www.practicingsafetechs.com/TechsV1/REST/, http://dmpc.dbp.fmph.uniba.sk/~rybar/it-software/docs/Integracia-SOA-REST.pdf)
- RESTovske WS volime vtedy ak sa jedna o Webovu aplikaciu a Webovu kommunikaciu.
- WS-* volime vtedy, ked nam ide o protokol agnostic interakciu medzi proprietarnymi alebo legacy systemami a zaroven si to zakaznik vyslovne zela (vendor lock :).

> Oproti tomu REST používá HTTP operace, které mají pevně definovaný význam (GET, PUT, POST, DELETE). Ovšem obsah sdělovaných zpráv (např. formát XML nebo JSON dat) často nebývá formálně (strojově čitelně – jako v případě WSDL) specifikován a je třeba použít dokumentaci nebo se jednoduše podívat na data, která služba vrací.

Ako suvisi strojova citatelnost reprezentacii v REST SW so strojovou citatelnostou WSDL?
Ak hovorime o SOAP v tomto kontexte, je potrebne povedat o ktorom s typov SOAP (RPC/literal, Document/literal, …) hovorime (http://www.ibm.com/developerworks/webservices/library/ws-whichwsdl/, http://www.eherenow.com/soapfight.htm). Je to totiz aj otazkou vykonu (http://www.ibm.com/developerworks/webservices/library/ws-soapenc/), co je dovodom, preco sa dnes preferuje SOAP Document/literal, v ktorom sa prenasa dokument a ked si odmyslime SOAP balenie pri tomto type, dostaneme RPC over HTTP (co je dalsia optimalizacia na vykon a prenesene data).

> Oproti tomu REST používá HTTP operace, které mají pevně definovaný význam (GET, PUT, POST, DELETE). Ovšem obsah sdělovaných zpráv (např. formát XML nebo JSON dat) často nebývá formálně (strojově čitelně – jako v případě WSDL) specifikován a je třeba použít dokumentaci nebo se jednoduše podívat na data, která služba vrací.

Ako je spomenute vyssie, pri preferovanom SOAP Document/literal tiez nie je format dokumentu/spravy formalne specifikovany, co nie je nedostatok, ale pozadovana vlastnost.

> Existuje popisný formát WADL, který by měl být tím, čím je WSDL pro SOAP služby, ale jedná se o poměrně mladou záležitost (oproti WSDL) a někteří vývojáři ho odmítají s tím, že není potřeba nebo že jde proti filosofii RESTu.

Nielen ze existenciu WADL odmietaju vyvojari, ale REST definuje sposob ako samopopisnosti sluzienb a teda WADL nema v ponimani RESTu zmysel. Ak sa hovori o existencii WADL v suvislosti s REST, je to dokaz nepochopenia RESTu a znacnej dezinterpretacie prace Roya Fieldinga.

> Pokud chceme implementoval libovolnou (i procedurální – RPC) službu pomocí REST služeb, lze to  – jen jsme trochu omezeni jednoduchostí RESTu a tím, že je určen k provádění CRUD operací a ne libovolných procedur. Tato omezení je možné obejít dvěma způsoby …

Z tejto vety je zrejme, ze autor clanku si dezinterpretuje REST. Nemozno RPC implementovat pomocou REST sluzby! Autor oznacuje pojmom REST nieco co je v skutocnosti HTTP-based RPC interface! Presne o tejto dost zavaznej dezinterpretacii pise sam Fielding na svojom blogu:
„I am getting frustrated by the number of people calling any HTTP-based interface a REST API. Today’s example is the SocialSite REST API. That is RPC. It screams RPC. There is so much coupling on display that it should be given an X rating.“ Roy Fielding (http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven)

> Např. Google od veřejného SOAP API upustil a používá REST – a to i pro typicky procedurální úlohy typu převeďAdresuNa­Souřadnice()  – viz jeho Geocoding Service. Zatímco jinde, kde se nepoužívají jen javascriptoví klienti, zase oceníte možnost silného typování SOAPu a možnost využití technologií jako je UDDI pro katalogizaci služeb a zvládání rozsáhlejších systémů.

Google SOAP API mozno zatial este ocenime, ale nie nadlho – http://googlesystem.blogspot.com/2006/12/googles-soap-search-api-no-longer.html.
Google skratka upustil od SOAP a od roku 2006 preferuje jedine REST API. A Google je spicka v IT a teda predpokladame, ze dobre vedia, preco to robia. My to vieme tiez. :)

Na zaver by som chcel napriek mojim vyhradam autora povzbudit k dalsej praci, lebo ako sa hovori „ucime sa cely zivot“.
Ako dokaz toho, ze aj ini architekti tapaju v rozdieloch WS-* a REST by som uviedol jeden prakticky priklad: http://dmpc.dbp.fmph.uniba.sk/~rybar/it-software/is-it-time-to-change-even-the-architect-not-just-architecture/
Ja sam som do tajomstiev RESTu prenikal dlhe roky a myslim, ze stale sa mam co ucit.

„RESTovske WS volime vtedy ak sa jedna o Webovu aplikaciu a Webovu kommunikaciu.“

Což je právě ten pragmatický přístup, o kterém jsem psal (a který nemusí být vždy v souladu s logikou a filosofií RESTu).

Ale co vybrat, když jsme na webu a potřebujeme procedurální API? Buď to zprasíme a budeme REST používat tak, jak se nemá (jako RPC) nebo si naopak upravíme svoje potřeby (vymyslíme si nějaké zdroje, aby šly napasovat na REST) a nebo REST jednoduše opustíme a použijeme jiný způsob (z toho pak vychází, že REST není tak univerzální jako SOAP služby, viz minulý díl seriálu – což neber jako kritiku RESTu, každá technologie má své použití a své hranice, to je normální).

„WS-* volime vtedy, ked nam ide o protokol agnostic interakciu medzi proprietarnymi alebo legacy systemami a zaroven si to zakaznik vyslovne zela (vendor lock :).“

Sorry, ale tohle mi přijde jako vyloženě házení špíny na SOAP webové služby. S proprietárním SW nic společného nemají – snad leda to, že existují i proprietární implementace – ale stejně tak lze realizovat SOAP WS klienta i server čistě pomocí neproprietární­ho/svobodného softwaru. A „vendor lock-in“? Klienta k RESTu i SOAPu mi může napsat kdokoli (tzn. nejsem vázaný na původního dodavatele) a pokud to rozhraní (definice SOAP služeb, metod, parametrů nebo naopak vnitřního formátu používaného v RESTu) bude nějak nestandardní a nenahraditelného čímkoli jiným, budu odkázaný na původního dodavatele bez ohledu na to, zda jde o SOAP nebo REST.

„Ako suvisi strojova citatelnost reprezentacii v REST SW so strojovou citatelnostou­ WSDL?“

U RESTu jsou strojově čitelná data (zdroje), která mi služba vrátí – ale jak zjistím, jaké má mít služba vstupní parametry nebo URL? Jako příklad si můžeme vzít ten Geocoding od Googlu (služba na převod adres na souřadnice).

URL vypadá takhle:
http://maps.google.com/maps/api/geocode/xml?sensor=false&address=_sem_přijde_adresa_

Jsou tu nějaké parametry (sensor, address, language atd.). Jak ale zjistím, jak se tyhle parametry jmenují? Jedině z dokumentace. V případě SOAP a WSDL bych si je zjistil právě v tom WSDL a dokumentace by dost možná ani nebyla potřeba, protože by mi došlo, že do address se bude dávat adresa. Ale když WSDL nemám, jak mám zjistit, že je to „address“ a ne třeba „addr“? WSDL je také možné použít pro vygenerování GUI pro obecnou službu (třeba na otestování, vyzkoušení) – vykreslí se formuláře pro jednotlivé parametry, jako třeba v tom ?Tester. U RESTu by něco takového snad šlo realizovat s tím WADL – jenže když nezapadá do filosofie RESTu a lidi ho odmítají používat, tak je to pak těžké.

„Ako je spomenute vyssie, pri preferovanom SOAP Document/literal tiez nie je format dokumentu/spravy formalne specifikovany, co nie je nedostatok, ale pozadovana vlastnost.“

Viz Loosely typed versus strongly typed Web services citovaný v článku. Pomocí SOAP služeb je možné udělat silně typované služby i slabě – v RESTu na výběr není, tam jsou obecně slabě typované (nepočítám MIME typ – mluvím o formátu přenášených dat, třeba toho XML).

„Nielen ze existenciu WADL odmietaju vyvojari, ale REST definuje sposob ako samopopisnosti sluzienb a teda WADL nema v ponimani RESTu zmysel. Ak sa hovori o existencii WADL v suvislosti s REST, je to dokaz nepochopenia RESTu a znacnej dezinterpretacie prace Roya Fieldinga.“

V podstatě souhlasím. Jen jde o to, že tohle důsledné dodržování filosofie RESTu celkem dost omezuje množství úloh, na které ho lze nasadit. Např. na jednom webu jsem nedávno narazil na aplikaci, která umožňuje navrhnout si vlastní terasu a spočítat její cenu (člověk zadá tvar a rozměry a vyleze mu z toho cena). Typická procedurální záležitost – předám parametry proceduře/funkci a ta mi vrátí výsledek. Žádné zdroje tu v principu nejsou – jen si můžeme vytvořit nějaké pseudozdroje. Kdybychom se řídili čistě logikou věci, tak bychom měli použít SOAP službu. Když budeme chtít použít REST, tak si můžeme vytvořit nějaký pseudozdroj jako „požadavek na výpočet ceny“ a ten pomocí RESTu vložíme (POST) a pak si vyzvedneme (GET) jiný zdroj s výsledkem výpočtu. Případně můžeme ty parametry funkce nacpat do URL jako GET parametry a provést vše v jednom kroku. Ano, je to překroucení a zneužití RESTu a možná už to ani není REST (technologicky ano, významově ne), ale dokážu pochopit, že někdo takovou aplikaci vytvoří (to jsou ty pragmatické důvody, z webu by se mu SOAP služba volala o něco hůř).

„Z tejto vety je zrejme, ze autor clanku si dezinterpretu­je REST.“

To je zase dezinterpretace článku :-) Píšu, že to lze a že to někteří dělají – ale ne, že by to bylo správné nebo že bych takový postup doporučoval. Viz „což ale neznamená, že bychom to nutně měli dělat“

„Google SOAP API mozno zatial este ocenime, ale nie nadlho“

Ty dvě věty byly možná trochu nešťastně v jednom odstavci hned za sebou. Ano, Google upustil od veřejného SOAP API a používá REST API (viz první věta).

„Google skratka upustil od SOAP a od roku 2006 preferuje jedine REST API. A Google je spicka v IT a teda predpokladame, ze dobre vedia, preco to robia. My to vieme tiez. :)“

A co ten Geocoding Service a spousta dalších příkladů v jejich API? Opravdu to Google dělá tak dobře a dodržuje striktně filosofii RESTu? Mně spíš přijde, že on si ho taky dost přiohnul, aby šel použít pro procedurální věci. Resp. neměli bychom tomu jeho API říkat REST, ale spíš „HTTP-based RPC interface“?

„ze dobre vedia, preco to robia.“

IMHO je to pragmatický ústupek klientům resp. programátorům na straně klienta a webovým aplikacím – snadněji se tam pracuje s RESTem (nebo s HTTP API) než se SOAPem. A taky asi neochota udržovat dvoje API pro jednu věc (náklady). Nějaké hlubší myšlenky bych v tom moc nehledal.

„ucime sa cely zivot“

+1 :-)

> Ale co vybrat, když jsme na webu a potřebujeme procedurální API?

Zhrnme si to:
- sme na webe
- REST definuje ako ma vyzerat dobre navrhnuta web aplikacia alebo sluzba
Teda ak potrebujeme na webe proceduralne API, chyba je niekde inde. Kde? Hmmm, medzi stolickou a klavesnicou?

> Buď to zprasíme a budeme REST používat tak, jak se nemá (jako RPC)

REST sa neda pouzit ako sa nema. Mozeme pouzit HTTP ako sa nema, ale nie REST!
Mozeme pouzit HTTP RPC API, ale to nema nic s RESTom. Jedina chyba takeho HTTP RPC API je, ze sa nim vzdalujeme od principov Webu a teda RESTu.

> Sorry, ale tohle mi přijde jako vyloženě házení špíny na SOAP webové služby. S proprietárním SW nic společného nemají

Tu som slovom proprietarny myslel specificky pre konkretnu korporaciu, nie urceny pre siroku verejnost alebo internet.

> A „vendor lock-in“?

No co si budeme nahovarat, zazili ako rozne implementacie SOAP, aplikacne kontajneri a verzie spolu nechcu fungovat? O tom, ze napr. B2B klient nevedel spravit klienta k nasmu SW?

> U RESTu jsou strojově čitelná data (zdroje), která mi služba vrátí – ale jak zjistím, jaké má mít služba vstupní parametry nebo URL?

Dobra otazka. To zistim z dokumentacie, alebo dostanem hotovu linku/formular v nejakej reprezentacii. To je ta samopopisnost – poslem kolegovi ktory ma nakodit klienta k sluzbam iba root URL mojich sluzieb a vsetko tam ma – to je REST. Takto to robime realne v praxi ked ma kolega naprogramovat AJAX UI k REST sluzbam (vid. http://prest.sf.net _docs_).
A otazka naspat. WSDL definuje operacie a typy vstupnych a vtstupnych dat, ale kde mam popis, co ktore data znamenaju?

A este maly technicky detail. Uz ste niekedy generovali WSDL pre sluzbu na serverovej strane, ktora bola naprogramovana v dynamicky typovanom jazyku (napr. Python)? Da sa vobec WSDL vygenerovat ked nemame staticky typovany jazyk? Alebo vy ste zatial zili iba v tom jednom svete Javy? Su aj ine svety a ine jazyky a maju na webe rovnako vyznamne postavenie.

Show me the interoperable, full and free implementations
of WS-* in Python, Perl, Ruby and PHP.
You won’t see them, because there’s no intrinsic value
in WS-* unless you’re trying to suck money out of your customers.

    Mark Nottingham, ex BEA, teraz Yahoo!
    http://www.mnot.net/blog/2006/05/10/vendors

> A co ten Geocoding Service a spousta dalších příkladů v jejich API? Opravdu to Google dělá tak dobře a dodržuje striktně filosofii RESTu? Mně spíš přijde, že on si ho taky dost přiohnul, aby šel použít pro procedurální věci. Resp. neměli bychom tomu jeho API říkat REST, ale spíš „HTTP-based RPC interface“?

Ano, nestastne sa vzdaluju od REST. Urcite sa to ich API da spravit cistejsie. Aj chalani v Googli sa maju este co ucit. :)

Ještě, že máme ten Jabber. Přes něj se dá líp pokecat než se dalekosáhle hádat v diskusi. :-) Na základních věcech se shodneme. Problém je tak trochu v tom, že REST je dnes tak oblíbený, že hodně firem/aplikací tyhle čtyři písmenka používá jako kouzelné zaříkávadlo a označuje tím svoje API, které ale vůbec není RESTové ale je to ve skutečnosti HTTP-RPC – a pak vznikají zbytečná nedorozumění.

Prosím Vás, kde jste přišel na to, že SOAP se „často vykládá spíše jako SOA Protokol“. Pracuji v oblasti SOA několik let, ale toto jsem ještě neslyšel. Naopak existuje (mylný) názor, že pro SOA potřebujeme SOAP. To není pravda. Pokud byste měl nějaký odkaz na „SOA protocol“, rád bych se poučil.

Bohužel JSR 224 není jedinou specifikací v Javě. Celkově je SOAP velmi roztříštěná věc a ve svém důsledku bohužel i komplikovaná. V praxi se často stane, že díky technickým problémům se spolu dva systémy prostě „nebaví“.

Ta dvě kritéria mi připadají dost uměle vytvořená. Technologii obvykle volíme jen tehdy, když vytváříme providera a ještě nevíme, kdo bude naše služby používat. Takto se ale obvykle webové služby nedělají – snad zrovna jen u společností jako je Google.

Pokud tvoříte aplikaci, u které se můžete s consumerem dohodnout, tak se prostě dohodnete. V businessu se obecně dává přednost SOAP. Pokud máte webovou aplikaci a chcete, aby ji lidé mohli „skriptovat“, hodí se víc REST.

Ad „Naopak existuje (mylný) názor, že pro SOA potřebujeme SOAP.“

To jistě ne a ani to v článku nepíšu. SOA je architektura (nebo styl architektury, jak by řekl Peter) a ta je nezávislá na protokolech – SOA se dá vybudovat klidně nad něčím jiným než SOAP/WS. Což ale nebrání přezdívat* SOAP jako SOA protokol. (tahle kritika mi přijde jako typický omyl v logice – něco jako když někdo z implikace A→B vyvozuje B→A a neprávem obviňuje druhého diskutujícího)

Původní význam té zkratky je „Simple Object Access Protocol“, jenže časem se ukázalo, že to zase tak „simple“ není, a proto se tenhle výklad už moc nepropaguje. Ve verzi 1.2 se od tohoto výkladu zkratky upustilo a radši se vůbec nerozvádí – prostě se píše SOAP. Zatímco ve verzi 1.1 můžeme ještě nelézt původní výklad (Simple Object Access Protocol).

Ad „V businessu se obecně dává přednost SOAP. Pokud máte webovou aplikaci a chcete, aby ji lidé mohli „skriptovat“, hodí se víc REST.“

Což je přesně ten pragmatický pohled. SOAP by si lidi nemohli jen tak „skriptovat“, takže se pragmaticky zvolí „REST“ a na logiku věci se kašle (i když se jedná o z principu procedurální věci, ohnou se tak, aby šly napasovat na „zdroje“ a použít „REST“).

A proč píšu REST do uvozovek? Protože to nakonec REST není, ale je to HTTP-RPC API (což ale není tak módní zkratka jako REST).

*) ostatně je to mnohem trefnější než původní „simple“.

Kromě toho, že SOAP není „simple“, tak on není ani „object“ a ani „protocol“. ;-)

No pěkně to vymyslili pánové tam nahoře…

Asi si to zatiaľ nikto nevšimol, no obrázok linkuje na URL file:///C:/DO­CUME%7E1/MARTIN%7E1­.MAL/LOCALS%7E1/Tem­p/netbeans-design.png