Magické slovo REST

V posledních letech jsem se několikrát setkal s tím, že lidé použili toto magické slovo téměř všude, kde se jim to zrovna hodilo. Jenže kolik z nich vlastně ví, co samotný REST znamená a v čem jsou jeho výhody a nevýhody oproti SOAPu?

V první řadě je třeba zmínit, že díky míchání pojmů je dnes dost matoucí se bavit jedním dechem o webových službách, RESTu, SOAPu či WSDL. Takže, jak to vlastně je:

Webová služba je obecný název pro systém na interakci mezi dvěma stroji po síti. Pokud někdo mluví o webové službě, tak tím vůbec nespecifikuje, zda se jedná o SOAP či REST.

SOAP je protokol na výměnu dat pomocí XML. Nejčastější využití je přes HTTP protokol.

WSDL popisuje samotný SOAP. Tedy určuje jak vypadá daná webová SOAP služba.

REST/REST API je architektonický styl, který má jasná pravidla. Nejčastější použití je přes HTTP protokol a jako výměnný formát používá XML, JSON či vlastní formát.

RESTful je označení aplikací, které využívají REST API.

Když jsem se poprvé setkal s pojmem REST, tak jsem nechápal jaké jsou jeho výhody oproti klasickému SOAPu. Díky tomu, že jsem k návrhu aplikací přes REST API přistoupil již před mnoha lety, tak ono zjišťování mám dávno za sebou.

Jak už jsem zmínil, REST je architektonický styl, tedy předem určuje jakou architekturu bude mít mé API. Osobně toto považuji za jeden z největších přínosů tohoto návrhu. Stejně jako v objektově orientovaném programování se používá pojem zapouzdření a programování vůči rozhraní, tak i zde jsem dopředu omezován. Ano správně! Omezován. A to je právě ona výhoda. Není totiž nic horšího, než se prohrabovat cizím API a zjišťovat jakým způsobem autor navrhl klientské volání onoho API.

Uvedu příklad:

Představte si, že máte program, který poskytuje službu pro práci se zaměstnancem. Aplikace je sofistikovaná a nabízí takové věci jako je tvorba nového zaměstnance, editace či mazání. Pokud takovou službu budu volat, tak budu nejspíše hledat názvy jako: Create, Update, Delete. Jenže, co když se autor rozhodl, že půjde jinou cestou? Najednou uvidím metody jako: AddEmployee, Save, Update, DeleteObject, DropEmployee. Asi si každý dokáže představit, co poté nastává. Prohledávání zdrojových kódů, dokumentace, volání na mobil autorovi, apod. Architektura RESTu je předem dána. Takže pokud autor zná alespoň základy dizertační práce pána jménem Roy Fielding, tak ví, jakým způsobem poskytovat jednotlivé služby.

Díky tomu, že je REST nejčastěji využíván společně s HTTP protokolem, tak využívá metody tohoto protokolu k přesně daným účelům:

• GET - získání záznamu
• POST - vytvoření nového záznamu
• PUT - aktualizace záznamu
• DELETE - odstranění záznamu

HTTP protokol obsahuje mnoho dalších metod, nicméně ty nejsou tak často využívány jako výše zmíněné. Existuje ovšem ještě jedna metoda, která je také specifikována a dost často ignorována. Osobně nevím proč, protože její využití spatřuji jako víc než důležitou.

• PATCH - aktualizace záznamu, ale pouze toho, co opravdu chci

Opět uvedu příklad:

Mám složitý objekt, který reprezentuji přes REST API. Při aktualizaci pomocí metody PUT očekávám, že přijdou všechna data a na základě identifikátoru aktualizuji jednotlivé položky. Jenže, co když nechci nutit klienta mého API, aby posílal všechny informace? K tomuto účelu se výborně hodí daná HTTP metoda PATCH.

Další důležitou vlastností RESTu je bezstavovost. Je třeba mít stále na paměti, že každé volání REST API je nový život. Mezi klientem a serverem neexistuje nic takového jako předchozí stav. Existuje spoustu důvodů, proč toto pravidlo porušit, nicméně všechny důvody mají svá řešení a proto bezstavovost API by vždy mělo být něco jako desatero:

• 1. Bezstavovost
• 2. Bezstavovost
• .....

Pokud se Vám podaří zbavit se dinosaura jako je HTTP Session, tak najednou zjistíte jak je svět RESTu úžasný. Volání čehokoli, odkudkoli, kdykoli. Klientské aplikace se zaměří pouze na to co je skutečně důležité a to zpracování Vašich zdrojů. Také škálovatelnost se stane něčím, co nebude nemožný úkol.

Poslední věcí, kterou zde dnes zmíním je verzování.

Každý autor takového API automaticky předpokládá, že jeho systém bude žít věčně a počet konzumentů jeho rozhraní bude vzrůstat. Proto hned od začátku začne počítat s verzováním.

Jak verzovat REST API je popsáno na mnoha místech a v podstatě je tímto i standardizováno. Tedy do URL adresy budu vkládat něco jako /api/v1/zdroj. Ideální varianta. Tedy alespoň na první pohled. Jenže skutečně to vždy potřebujeme? Jak se vypořádáme s verzováním na úrovni samotného kódu? Co zpětná kompatibilita? Otázek, na které nikdo předem nezná odpověď je příliš mnoho. Něco mi mohou pokrýt testy, ale buďme upřímní. Skutečně nás testy spasí od všech problémů? Tak tedy ještě jednou. Opravdu potřebujete své API verzovat? Pokud ano, je třeba mít na paměti několik důležitých pravidel:

• Verzuji vždy celé API, nikdy ne jen jeho část
• Verzování jasně specifikuji buď v URL adrese či pomocí HTTP hlavičky
• Pokud jsem konzumentem svého API pouze já, snažím se verzím spíše vyhnout
• Udržuji zpětnou kompatibilitu jen do té úrovně, do které mi to dovolují zdroje, které pro vývoj mám. Krásně by se mi mohlo totiž stát, že víc času budu trávit řešením zpětných kompatibilit, než se věnovat skutečným problémům.

K verzování se jednou vyjádřil i samotný Roy Fielding. Ve zkratce napsal něco jako: "Verzujte své API pouze pokud je to skutečně nutné. Mnoho lidí totiž zbytečně jde s kanónem na vrabce. A pokud už verzování potřebujete, tak ho fyzicky oddělte. Tedy zdroje budou mít jinou adresu. Je to něco, jako když si představíte, že jste vytvořili nový web na nové adrese."

O RESTu by se dala napsat kniha. Témat, která se kolem tohoto slova točí je skutečně mnoho. V dnešní době se z RESTu stal v podstatě standard pro tvorbu Backend API. Však také vznik věcí jako je AngularJS, ASP.NET MVC, Spring Data REST, apod tomu jen nahrávají.

Příště se pokusím zmínit o tom, co znamená HATEOAS, jak si poradit s autentifikací a autorizací či jaké jsou nevýhody RESTu.