REST: architektura pro webové API

Web 2.0 přinesl, kromě oblých rohů, pastelových barev a velkých písmen, především intenzivnější spolupráci serverů mezi sebou při výměně dat. Do popředí zájmu se tak dostaly pojmy jako jsou API, webové služby či vzdálené volání procedur. Spolu s nimi se začal intenzivně skloňovat termín REST. Pojďme si jej podrobněji představit.

REST

REST (Representational State Transfer) – viz definice REST na Wikipedii – je architektura rozhraní, navržená pro distribuované prostředí. Pojem REST byl představen v roce 2000 v disertační práci Roye Fieldinga, jednoho ze spoluautorů protokolu HTTP. Proto nepřekvapí, že REST má s HTTP hodně společného.

REST je, na rozdíl od známějších XML-RPC či SOAP, orientován datově, nikoli procedurálně. Webové služby definují vzdálené procedury a protokol pro jejich volání, REST určuje, jak se přistupuje k datům.

Rozhraní REST je použitelné pro jednotný a snadný přístup ke zdrojům (resources). Zdrojem mohou být data, stejně jako stavy aplikace (pokud je lze popsat konkrétními daty). Všechny zdroje mají vlastní identifikátor URI a REST definuje čtyři základní metody pro přístup k nim.

Metody pro přístup ke zdrojům

REST implementuje čtyři základní metody, které jsou známé pod označením CRUD, tedy vytvoření dat (Create), získání požadovaných dat (Retrieve), změnu (Update) a smazání (Delete). Tyto metody jsou implementovány pomocí odpovídajících metod HTTP protokolu.

GET (Retrieve)

Základní metodou pro přístup ke zdrojům je získání zdroje – metoda GET. Setkává se s ní každý uživatel webu dnes a denně – není to nic jiného než starý dobrý požadavek na stránku.

GET /api/user/pepa
Host: www.server.cz

Jak jsme si už řekli, má každý zdroj (resource) podle rozhraní REST vlastní identifikátor (URI). Pomocí HTTP GET požadavku získáme data konkrétního zdroje. Ukažme si praktický příklad – získání posledních zpráv konkrétního uživatele (bude to „lupacz“) na Twitteru. Twitter poskytuje pro přístup k datům právě rozhraní REST (jeho API je, řečeno terminologií, RESTful – myslím ale, že se volný překlad „RESTovací“ pravděpodobně neujme, což je škoda, pozn. aut.).

Podle dokumentace REST API Twitteru lze získat zprávy konkrétního uživatele jako zdroj „/statuses/user_ti­meline“. Přesný tvar je http://twitter.com/statuses/user_timeline/uživatel.formát. Data uživatele „Lupacz“ ve formátu XML získáme tedy takovýmto HTTP požadavkem:

GET /statuses/user_timeline/lupacz.xml
Host: twitter.com

Což odpovídá téměř naprosto přesně požadavku, který webový prohlížeč odešle, když klikneme na následující odkaz: http://twitter­.com/statuses/u­ser_timeline/lu­pacz.xml – můžeme si tedy sami velmi jednoduše vyzkoušet, jak vypadá výsledek. Můžeme zkusit změnit formát dat – máme na výběr XML, JSON, RSS a ATOM. Takto například vypadá tentýž zdroj, když je formátován jako RSS: http://twitter­.com/statuses/u­ser_timeline/lu­pacz.rss

API služby Twitter je poměrně dobrým příkladem rozhraní, které je postaveno na architektuře REST, a tak jeho studium může sloužit jako dobrý odrazový můstek pro prozkoumání možností podobných RESTful API.

Pokud potřebujeme získaná data nějak upravit či filtrovat, můžeme je předat jako součást požadavku tak, jak jsme zvyklí – jako tzv. „Query parametry“, tedy za otazníkem. Například http://twitter­.com/statuses/u­ser_timeline/lu­pacz.xml?count=100

POST (Create)

Získání dat je jednoduché a přímočaré. Stejně tak i vytvoření dat bude většině webových vývojářů připadat povědomé. Pro vytvoření dat slouží totiž metoda POST, známá (minimálně) z HTML formulářů.

U metody POST není ve chvíli volání známý přesný identifikátor zdroje (logicky, protože zdroj ještě neexistuje). Proto se pro POST používá domluvený společný identifikátor („endpoint“). Znovu se podíváme na ilustraci na konkrétním příkladu služby Twitter.

K vytvoření dat (zprávy) je potřeba zavolat zdroj s URI „/statuses/up­date“ pomocí HTTP metody POST. V parametru „status“ se předává text pro nově vytvořenou zprávu. Vzhledem k tomu, že vytvoření nové zprávy ovlivňuje uživatelská data, je třeba, aby volání bylo autorizováno. Twitter podporuje dvě metody autentizace: prostá HTTP autentizace nebo OAuth. OAuth poskytuje mnohem větší úroveň zabezpečení než prostá HTTP autentizace, při níž se posílá jméno a heslo v otevřeném textu, navíc umožňuje vytvářet aplikace, které využívají API, aniž by potřebovaly znát uživatelovo jméno a heslo. Implementace OAuth však není triviální, proto si pro zjednodušení ukážeme použití POST metody s jednoduchou HTTP autentizací.

curl -u user:password -d "status=Zkousime REST API" http://twitter.com/statuses/update.xml

Po odeslání by měl server vrátit patřičný návratový kód – HTTP má k tomu účelu stavový kód 201 – Created, v němž lze předat URI nově vytvořeného zdroje. Pokud došlo k chybě, měl by server vrátit chybový kód.

DELETE

Zdroj lze smazat pomocí volání URI HTTP metodou DELETE. Volání je obdobné volání metody GET:

DELETE /api/user/pepa
Host: www.server.cz

V praxi bývá někdy problematické vyvolat HTTP metodu DELETE – spousta HTTP nástrojů či HTML formuláře jsou omezeny pouze na metody POST a GET. V praxi se proto u REST rozhraní používají náhradní způsoby – např. volání pomocí POST s parametrem, který sděluje, že má být ve skutečnosti použita metoda DELETE, nebo speciální URI:

http://twitter.com/statuses/destroy/číslo.formát

Pokud máme nástroj, který umožňuje vyvolat metodu DELETE, můžeme ji použít:

curl -u user:password --http-request DELETE http://twitter.com/statuses/destroy/1472669360.xml

PUT (Update)

Operace změny je podobná operaci vytvoření (create, metoda POST), s tím rozdílem, že voláme konkrétní URI konkrétního zdroje, který chceme změnit, a v těle předáme novou hodnotu (jako u metody POST). Na rozdíl od POST je u úprav zdroje jeho URI už známá, takže ji lze zadat.

U metody PUT platí totéž, co bylo napsáno výše o metodě DELETE: Ne každý nástroj ji podporuje, a proto některá RESTful API používají různé náhradní metody, jak bylo zmíněno výše. Například:

curl -u user:password -d "url=http://zdrojak.root.cz" http://twitter.com/account/update_profile.xml

Shrnutí

REST je architektura, který umožňuje přistupovat k datům na určitém místě pomocí standardních metod HTTP (HTTP 1.1 methods). Pomocí REST lze ovládat i stav aplikace, pokud jej dokážeme popsat takovým způsobem, že si vystačí s modelem „zdroje – CRUD akce“.

REST nabývá na významu a stává se spolu s JSON defacto standardem pro API webových služeb. Jeho rozšíření napomáhá i technika AJAX, které REST vychází vstříc. Jeho rozšíření napomohlo i to, že se nijak zásadně neliší od standardního volání a získávání dat pomocí HTTP, pouze je zobecňuje. Dá se říct, že REST je architektura, která umožňuje CRUD operace pomocí standardních HTTP dotazů. (Pokud vám pojem CRUD stále evokuje databázové tabulky, tak jste na správné stopě – a ano, existuje nástroj, který funguje jako REST rozhraní k databázi.)

Moderní frameworky pro vývoj server-side aplikací pomáhají vytváření REST rozhraní tím, že dokáží nadefinovat patřičné procedury pro všechny potřebné metody, takže vytvoření vlastního RESTful rozhraní je opravdu snadné. Čím dál tím častěji je vidět v přehledech vlastností frameworků kromě (např.) „Podporuje MVC“ i „Podporuje REST“.

REST svou bezestavovostí vychází vstříc moderním metodám vývoje webových aplikací, které jsou založené na paralelním zpracování distribuovaného obsahu. Tato jeho vlastnost, spolu s výše zmíněnými výhodami (jednoduchost a nenáročnost) naznačuje, že se s rozhraními, postavenými na modelu REST, budeme do budoucna setkávat stále častěji.