„Znovuzjednotenie webu“. Aj takýto názov má jedna z kapitol knihy RESTFul web services od Leonarda Richardsona a Sama Rubyho. Kniha nie je len popisom toho, ako REST sieťové služby vyzerajú, ale hlavne silnou obhajobou, prečo ich používať. A tiež toho, prečo sú v prostredí internetu viac prirodzené ako ich staršie príbuzné – SOAP služby.
Jednou z hlavných myšlienok, ktorá sa prelína celou knihou je, že SOAP služby posunuli používanie internetu (ako množiny rôznych štandardov) do úrovne, ktorá je silne vzdialená jeho zvyšku.
Aby ste rozumeli o čom hovorím, tu je ukážka z toho, ako fungoval HTTP protokol niekedy v jeho úplnom začiatku:
Požiadavka klienta: GET /hello.txt (vypýtanie si súboru hello.txt)
Odpoveď: Hello, world! (obsah súboru hello.txt)
HTTP bol vytvorený na získavanie dokumentov zo servera – to, na čo kedysi vznikol internet ako výmenná sieť údajov medzi vysokými školami. Od tých čias už prešla dlhá cesta a niekde na tej ceste sa začali používať SOAP služby. Zatiaľ čo v pôvodnom protokole bolo jasné, čo chcete robiť a s akými údajmi už na úrovni HTTP („GET“ – čo chcem robiť, „/hello.txt“ – s akými údajmi), SOAP služby priniesli RPC štýl, kedy sa stále vykonávajú dotazy na jednu URL adresu pomocou POST príkazu. To, čo sa vlastne má udiať medzi klientom a serverom je ukryté v tele dotazu v SOAP správe. To je práve ten rozdiel oproti klasickým web stránkam, ktoré si čiastočne zachovávajú pôvodný štýl – čo iné údaje, to iná URL (aj keď už aj v tejto oblasti nastal odklon napríklad vďaka Ajax-u).
A v tomto momente sa dostávame k tomu znovuzjednoteniu, o ktorom som písal úplne na začiatku. Čo ak by sme vedeli navrhnúť služby tak, aby sa podobali stránkam? Vrátiť sa z odbočky, ktorú predstavujú SOAP služby a skúsiť zachovať základné pravidlá webu. Riešením novej generácie by mali byť REST služby…
REST služby sú hlavne o menšom počte štandardov a ich väčšom využití. Tie štandardy sú vlastne tri: HTTP, URI a XML (alebo JSON, alebo XHTML atď.). To je všetko, čo potrebujete poznať, ak chcete komunikovať s REST službami. Základná myšlienka je, že URI definuje údaje, s ktorými chcete pracovať a HTTP operáciu, teda čo s údajmi chcete spraviť. Ak ste sa doteraz stretávali s dvoma operáciami GET a POST, tak vedzte, že HTTP ich má ešte viac. Napríklad PUT, DELETE, HEAD a OPTIONS. To už je celkom slušný arzenál na to, aby ste na tom vedeli postaviť nejakú infraštruktúru. GET a POST získali svoju slávu hlavne preto, lebo sa používajú na štandardom webe (GET na získanie údajov stránky a POST na odoslanie výsledkov formulára).
A to je v podstate všetko – ideálne by to malo byť takto jednoduché. Napríklad
PUT /hodas/issue
môže byť vloženie nového problému do systému evidencie chýb pre projekt s názvom hodas (údaje tohto nového problému sú zapísané v tele HTTP dotazu pomocou niektorého popisného formátu, ktoré som spomínal hore). Ako bude URI vyzerať a ako bude interpretovaná už závisí čiste na tvorcovi systému. Najväčší rozdiel medzi SOAP a REST je teda hlavne v tom, ako komunikujte so serverom – aké štandardy a ako ich používajú. Naopak, metóda, ktorá obslúži túto požiadavku na serveri napísaná v nejako programovacom jazyku môže byť veľmi podobná v oboch prípadoch. Samozrejme, že potrebujete nejaký REST framework, ktorý na základe URL zavolá správnu metódu (tie sú dnes ale pre každú populárnu platformu – kniha tiež obsahuje zoznam a príklad použitia pre niekoľko z nich).
Zaujímavou vlastnosťou REST-u je, že v odpovedi, ktorá príde zo servera môžu byť zapísané odkazy na iné údaje – teda URL. Takto si viem na základe prvej odpovede získavať ďalšie údaje. To je nepochybne vlastnosť, ktorá sa v SOAP službách dosahuje len ťažko a je to tiež krok späť ku klasickému webu, kde je previazanie hyper-linkami bežná záležitosť.
REST služby nie sú žiadne ideálne riešenie na všetky prípady. Aj keď čerpajú z jednoduchosti a toho, že sa viac podobajú na klasické stránky, existujú oblasti, kde ich použitie nie je také jednoduché ako pri SOAP službách. Sú to napríklad rôzne kroky procesov v komunikácii medzi klientom a serverom. Príkladom môže byť realizácia jednej transakcie v rámci viacerých služieb, asynchrónne operácie alebo zložité bezpečnostné a komunikačné požiadavky, ktoré dokážu obslúžiť WS-* štandardy. Napriek tomu sa zdajú REST služby o čosi lepšie ako SOAP. Už len preto, lebo sú jednoduchšie. A to je v softvérovom svete, kde zložitosť môže byť jedným z najväčších problémov, veľmi zaujímavá vlastnosť.