Přeskočit na hlavní obsah

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.

Komentáře

Populární příspěvky z tohoto blogu

Jak si v IT vydělat hodně peněz?

Na začátek by bylo dobré, abych objasnil samotný titulek, který může na někoho působit jako červený hadr. Článek nebude o obecných pravidlech, ale bude vyprávět můj vlastní příběh, na kterém vám zkusím ukázat, jak se dá docílit úspěchu, či alespoň správně nastartovat svojí vlastní kariéru v IT.

I když se z názvu článku dá dedukovat, že se vše bude točit kolem peněz, není tomu tak. Alespoň ze dvou třetin určitě ne. Ale to už předbíhám, pojďme to raději vzít hezky popořadě...

Kdybychom měli mluvit o roce 2017 jako o přelomové době, nejspíše to nebude pravda. I když pro někoho to může být rok plný úspěchů a štěstí v podobě narození zdravých dětí, svatby či první velké lásky, tak z pohledu lidstva se jedná o rok, který jen kopíruje předešlé a v oblasti technologií nás posouvá stejným tempem jako rok předtím.

Jsem naprosto přesvědčen o tom, že i když se současná doba tak nenazývá, tak prožíváme dobu, která jednou bude označena za revoluční, a to zejména díky vynálezu internetu, který je st…

Jak by se firmy neměly chovat k programátorům?

Každý, kdo pracuje v IT oboru, se jistě již setkal s různými „geniálními nápady“, od kterých si firma slibovala zlepšení produktivity či snížení nákladů. Ať už je to zavedení agilních principů, striktní kontrola práce či zavedení nové a skvělé metodiky, o které si „šéf“ přečetl včera na internetu. Jsou z toho skutečně tak nadšení i samotní vývojáři? A bude nový nápad fungovat?
K napsání tohoto článku mě navedly různé programátorské diskuze, kde si lidé stěžovali na firmu, kde pracují. Příklady, které zde uvedu, jsou z reálné praxe. Ať už jsem je zažil jako řadový programátor, či jako šéf týmu.
I když je poptávka po programátorech tak vysoká, že Vás headhunteři nahánějí i ve chvílích, kdy o to opravdu nestojíte, tak i přes to je mnoho lidí, kteří se bojí opustit svoje současné zaměstnání.
Čeho se nejčastěji bojíme? Je to samozřejmě nejistota, kterou si často omlouváme větami jako: „Tady mám své pohodlí, co když to jinde mít nebudu?“ nebo „I když mě to v práci štve a nebaví, tak mě ale…

Jak jsem technologicky postavil startup

Tento příběh pojednává o technologiích, nástrojích a vůbec o všem, co jsem potřeboval k tomu, abych byl schopen, postavit startup na zelené louce.

Každý správný příběh začíná stejně: "Jednou jsem...."

Kapitola první: Nápad
Jednou jsem se setkal s člověkem, který měl nápad na produkt, který se v průmyslu zatím nevyskytuje. I přes prvotní skepsi, kdy jsem si říkal: "Tohle už přeci dávno v průmyslu existuje, ne?", jsem došel ke zjištění, že nikoli.

Tím jsem se dostal ke svému prvnímu poučení. Průmysl je technologicky dost zabržděný. Osobně se domnívám, že těch důvodů, proč tomu tak je, je několik. Za prvé je to fakt, že většina lidí, kteří se pohybují v tomto odvětví jsou často konzervativní a za správné považují pouze léty osvědčené věci. Druhým důvodem je to, že jakákoli změna znamená riziko. Ať už z pohledu finanční ztráty tak i z pohledu stability výroby. No a třetím a nejzásadnějším důvodem je to, že ač zde máme spousty technologických vymožeností, narážíme na to,…