Názory k článku
Java na webovém serveru: píšeme REST API

V ostré instalaci jsem trochu změnil mapování URL, takže např. článek č. 1 najdete na http://nekurak.net/rest/clanek/1

Uživatel zdrojak.root.cz má heslo „heslo“ a má přiřazenou roli redaktor, takže si můžete vyzkoušet i posílání, editaci a mazání. (jen prosím, nemažte všechno a neposílejte zbytečně moc záznamů).

Pokud by někoho zajímal WADL popis služby (něco na způsob WSDL ale pro REST), najde ho tady: http://nekurak.net/rest/application.wadl (automaticky generovaný frameworkem bez nějakých zvláštních úprav).

IT architektura je skutocne tazka, je to „umenie“.
Najma REST castokrat vyvolava dojem, ze je jednoduchy a niektori architekti si ho v praxi mylia s HTTP API. V tejto suvislosti si dovolim poukazat na par nedostatkov. Dufam, ze to nenarusi moje dobre vztahy s autorom clanku.

Chcel by som poukazat na maly nedostatok prezentovaneho REST API. REST API by malo okrem ineho splnat podmienku prelinkovanisti reprezentacii.
Myslim ze vystizne o tom pise sam otec RESTu vo svojom clanku http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven
V tejto suvislosti je sporne, ci by mal existovat popisny jazyk ako WADL.
Zrejme NIE! Nakolko REST API by malo byt samopopisne.
WADL je akousi analogiou WSDL, ktory sa do implementacii dostava nevhodnym chapanim REST sluzieb ako analogie so SOAP sluziebami.
Dufajme ze hlbsia znalost REST architektonickeho stylu povedie v buducnosti k cistejsim implementaciam nastrojov pre podporu REST architektonic­keho stylu.

Niekedy je tazke sa rozhodnut kedy SOAP a kedy REST.
Mala pomocka: http://dmpc.dbp.fmph.uniba.sk/~rybar/it-software/docs/Integracia-SOA-REST.pdf

Zatím jsem přečetl jen část prezentace, ale už bych měl jeden dotaz: je REST podle tebe SOA nebo ROA? :-)

(strany 10 a 30)

Napisem ako to chapem ja, lebo s touto otazkou zapasim uz dlhsie.

SOA je akysi dost abstraktny pojem vyjadrujuci sposob ako riesit architekturu softverovych systemov zalozenu na poskytovateloch sluzieb konzumentom. Nespecifikuje akym sposobom su sluzby a komunikacia realizovane.

ROA je podmnozina SOA, ktora hovori, ze sluzby su realizovane prostrednictvom zdrojov. Tato architektura nie je nijak viazana na Web, alebo HTTP. Mozeme mat napriklad ROA implementovanu nad lubovolnym komunikacnym protokolom, ktory splna podmienky referencovania zdrojov, CRUD operacii a reprezentacii.

REST je styl softverovej architektury, pri ktorom ked dodrzime vsetky jeho pravidla, tak nasa konkretna implementacia/ar­chitektura bude ROA. REST je navyse taka sada pravidiel, ktora definuje ako realizovat ROA na Webe. A Web a HTTP bol vo svojej podstate navrhnuty podla istych pravidiel (Fielding videl ako ich ludia ignoruju a tak ich neskor, davno po zrode webu spisal a pomenoval – REST). REST definuje spravny sposob ako pouzivat HTTP, URL, a typy dokumentov/re­prezentacie (plus nejake dalsie pravidla tykajuce sa prelinkovania a tranzakcnosti).

A este asi to co som mal povedat asi na zaciatku:

– Architektonicky styl – je sada pravidiel, ktore vymedzuju ako bude vyzerat konkretna implementacia architektury (architektura samotna).

– Architektura – je to, co vznikne syntezou architektonickeho stylu a schopnosti/umenia konkretneho architekta (akysi folklor, osobitost).

Teda ked hovorime napriklad o SOA ako architekture, myslime tym istu mnozinu konkretncyh/po­tencialnych implemtacii podla pravidiel SOA, kde ale vysledok bude zavisiet od toho akeho architekta implemntaciou poverime.
Myslim, ze je preto lepsie hovorit o architektonickom style nez o architekture, pokial nehovorime o konkretnej implemntacii v ktorej je uz vpisany rukopis architekta.

SOA je v sucasnosti pojem dost znetvoreny „enterprice architektami“, ktori si ho automaticky asociuju s nejakou architekturou ktora pouziva na komunikaciu protokol SOAP.
Mozno prave pre svoju neurcitost je pojem SOA tak oblubeny v korporatnej sfere. Tazko vam odberatel dokaze ze to co sa vam podarilo nie je SOA. :)

„ROA je podmnozina SOA…“

Takhle nějak chápu vztah mezi REST a SOAP. REST mi umožňuje volat CRUD „procedury“ (provádět CRUD operace), zatímco SOAP mi umožňuje volat libovolné procedury, SOAP je obecnější – což je jak výhoda, tak i nevýhoda. V případě RESTu jsem omezen na CRUD, ale zase mám standardizované rozhraní – pokud budu dělat CRUD pomocí SOAP služeb, samozřejmě to lze, ale budu si muset vymyslet nějaké vlastní konvence, názvy procedur/operací – což u RESTu dělat nemusím, tam použiji všeobecně uznávané konvence a HTTP operace jako jsou PUT, GET, POST…

Ovšem mezi ROA a SOA podle mého vztah „podmnožina“ není. ROA je data-centrická architektura. Příklad: když se budu dívat na firemní IS jako z hlediska zdrojů, uvidím ho rozparcelovaný podle jednotlivých aplikací nebo úložišť dat – např. tu budu mít mzdový systém (kde mohu dělat CRUD operace se zdrojem „zaměstnanec“), poštovní server (kde jsou zdroje „schránka“, „uživatel“, „zpráva“), firemní telefonní seznam (kde je zdroj „kontakt“)… Oproti tomu SOA umožňuje seskupit určitou funkcionalitu napříč různými datovými úložišti a zapouzdřit ji do něčeho, čemu říkáme služba. Takže pak budu mít třeba službu „přijmi nového zaměstnance“, které předám všechny potřebné údaje, a ona přidá zaměstnance do mzdového systému, vytvoří mu poštovní schránku, nastaví hesla, přidá ho do firemního adresáře atd. – provede řadu operací nad různými datovými úložišti.

> Takhle nějak chápu vztah mezi REST a SOAP. REST mi umožňuje volat CRUD „procedury“ (provádět CRUD operace), zatímco SOAP mi umožňuje volat libovolné procedury, SOAP je obecnější – což je jak výhoda, tak i nevýhoda.

Dovolim si nesuhlasit, ze SOAP je vseobecnejsi nez REST.
Porovnavat SOAP a REST sa dobre neda. Analog SOAPu v kontexte REST je HTTP.
Jedine, co ma SOAP s RESTom spolocne je, ze SOAP pouziva/degraduje aplikacny protokol HTTP na transportny protokol.

REST ma fixny pocet operacii (CRUD) a „nekonecny“ priestor identifikatorov zdrojov. Tento princip je zakladom UNIXov, filesystemov, relacnych databaz. Je dobre prevereny. A na tomto principe bol postaveny aj HTTP ako aplikacny protokol vysej vrstvy pre webove aplikacie.
Je lahsie publikovat zoznam zdrojov ak operacie nad nimi su dobre definovane, ako publikovat operacie a ich vstupy a vystupy (v pripade SOAP je preto nevyhnutna existencia WSDL).

WS-* maju zasa jediny endpoint a „nekonecny“ priestor mien operacii (pre klienta je to ako keby ste si pri kupe bytu prezerali izbu cez klucovu dierku).

> Ovšem mezi ROA a SOA podle mého vztah „podmnožina“ není.

To je dost sporne, zavisi ako je definovane SOA.
SOA – sluzba je identifikovana operaciou, alebo identifikatorom zdraoja, alebo, …
ROA – sluzba je identifikovana identifikatorom zdraoja

> Oproti tomu SOA umožňuje seskupit určitou funkcionalitu napříč různými datovými úložišti a zapouzdřit ji do něčeho, čemu říkáme služba.

To iste mozeme povedat o ROA. Aj resource je sluzba, ale prezentovana inou formou.
SOAP: ziadam server o realizaciu operacie X nad datami Y
REST: ziadam server aby nad datami Y realizoval operaciu X

Takze mozeme si vytvorit virtualny resource „/zamestnanci“, ktoremu metodou POST posleme data noveho zamestnanca, a tento virtualny resource prida data zamestnanca do vsetkych podsystemov. Metoda PUT by sposobila napriklad aktualizaciu udajov a DELETE vymazanie udajov zamestnanca vo vsetkych podsystemoch.

Este by som dodal, ze zakladnym REST rozhranim z hladiska Javy je Servlet.
Teda najvseobecnejsim REST aplikacnym serverom je servletovy kontajner.
Dalsie nadstavby a frameworky su iba vecou vyssieho komfortu pri mapovani dat z webovych textovych/binarnych reprezentacii do nativnych datovych typov a reprezentacii v Jave.

Posun smerom k REST sluzbam je hlavne o tom ako:
- zjednodusit technologicky stack
- znizit naklady na vyvoj
- maximalizovat vykon (podobne ako dalsia faza posunu od RPC/literal ku document/literal v SOAP)
- efektivita pri prenose dat (cacheovanie dat mino aplikacnu logiku)
- skalovatelnost (decentralizacia, geo-dislokacia)

HTTP má „transportní protokol“ už v názvu, takže o degradaci nemůže být řeč ani omylem (to, že někdo použije pouze podmnožinu funkčnosti je věc druhá, daná úrovní znalostí a zkušeností – ovšem to je snad nejobecnější problém)

Dále, o snížení nákladů na vývoj se dá pochybovat:
- existuje několik málo frameworků s lepší či horší podporou pouze pro vystavení zdrojů, většinou málo/špatně zdokumentovaných
- dostupné nástroje (v podstatě žádný speciální REST tooling neexistuje) nepokrývají problematiku integrace a alespoň přípravu závislého prostředí (když už REST nepokrývá např. bezpečnost (bavíme se např. o bezpečnosti na úrovni obsahu zpráv – zde nestačí per server SSL) apod.

Také bych rád vyvrátil nebo alespoň zpochybnil několik účelových dogmat:
- „koupě bytu přes klíčovou dírku“ – např. reálné používání webu (což opodstatňuje vůbec existenci http) je pro člověka vázané na DNS, které ve své architektuře taktéž využívá „endpointy“ (berte jako analogii)
- základním běhovým prostředím pro WS- je opět servlet container, takže tvrdit např. ve Vámi dostupném PDF, že se nasazuje REST na „web server“ a SOAP na „web services container“ je prostě účelové (pokud se bavíme vůbec o aplikaci a ne statickém obsahu, pak oboje potřebuje buď dostupné knihovny (frameworky) nebo máte v obou případech možnost to dělat manuálně
- v případě poskytování rozhraní partnerům (B2B) může být např. WSDL jediným zdrojem dokumentace, u REST to člověk musí explicitně popsat formou další dokumentace (kterou musí zároveň distribuovat)
- v obou případech (opět narážím na uvedené PDF) musíte mít jasný datový model

Soukromé resumé:
- REST = vhodný pro jádro aplikace (tj. na komunikaci mezi frontend a backend, pokud máte vícevrstvou aplikaci – ano, škálování probíhá i vhodným rozvrstvením aplikace) NEBO na jednodušší scénáře
Výhodou je samozřejmě menší overhead na zpracování)

– SOAP = v případě že: API vystavuji do reálného světa nebo existuje složitější scénář (atomic security, routing …)

P.S.: osobně se mi REST líbí, ovšem před sebou má ještě dost velkou cestu (jestli vůbec přežije do doby, než přijde někdo další, kdo opráší kolo)

Ještě dodám:

I když je HTTP skoro jediným transportním protokolem SOAPu, tak tento na něj není vázán, takže je otázka, zda vůbec a do jaké míry se dá REST a WS porovnávat.

Pro zajímavost (anglicky):
http://www.prescod.net/rest/rest_vs_soap_overview/

> HTTP má „transportní protokol“ už v názvu

The Hypertext Transfer Protocol (HTTP) is an Application Layer protocol for distributed, collaborative, hypermedia information systems. (http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol).
Pouzit aplikacny protokol len ako transportny je degradacia!

> dostupné nástroje (v podstatě žádný speciální REST tooling neexistuje) nepokrývají problematiku integrace a alespoň přípravu závislého prostředí (když už REST nepokrývá např. bezpečnost (bavíme se např. o bezpečnosti na úrovni obsahu zpráv – zde nestačí per server SSL) apod.

Tu je vidiet, ze nechapete ani co je WS-*. REST pokryva omnoho sirsiu oblast ako WS-*. WS-* je iba interoperability standard, Nikdy neriesil integraciu ani aplikacnu architekturu. REST je architektonicky styl Webu, riesi reprezentaciu dat, referoncaovanie dat, sklovatelnost, cacheovanie, prelinkovanie, tranzakcnost, …

> Také bych rád vyvrátil nebo alespoň zpochybnil několik účelových dogmat:

Spochybnim Vase dogmy.

> – „koupě bytu přes klíčovou dírku“ – např. reálné používání webu (což opodstatňuje vůbec existenci http) je pro člověka vázané na DNS, které ve své architektuře taktéž využívá „endpointy“ (berte jako analogii)

Tato veta jednoducho nedava zmysel. DNS nemozno v REST kontexte ani pri najlepsej voli chapat ako endpoint. Pouzivate nespravnu terminologiu.

> – v případě poskytování rozhraní partnerům (B2B) může být např. WSDL jediným zdrojem dokumentace, u REST to člověk musí explicitně popsat formou další dokumentace (kterou musí zároveň distribuovat)
- v obou případech (opět narážím na uvedené PDF) musíte mít jasný datový model

WSDL NEMOZNO povazovat za zdroj dokumentacie!
Mozete nam v Example WSDL file na strane http://en.wikipedia.org/wiki/Web_Services_Description_Language ukazat, kde je zakodovana ta dokumentacia? Popis datoveho rozhrania za dokumentaciu snad nepovazujete.

> – REST = vhodný pro jádro aplikace

Ak je REST dost dobry na to aby sme v nom spravili jadro, je dost dobry na celu plikaciu.

> – SOAP = v případě že: API vystavuji do reálného světa nebo existuje složitější scénář (atomic security, routing …)

Ak ste v zivote nevideli API Googlu, Yahoo, alebo Amazonu, tak zrejme ich predstava realneho sveta je ina nez ta Vasa.

> P.S.: osobně se mi REST líbí, ovšem před sebou má ještě dost velkou cestu (jestli vůbec přežije do doby, než přijde někdo další, kdo opráší kolo)

REST reprezentuje principy a architekturu Webu. Vznikol s Webom a kym tu bude Web, bude tu aj REST. Velku cestu budu musiet prejst ti, ktori ho nechapu ak ho chcu pochopit. :)