Representational State Transfer

Representational state transfer (REST) je termín z [url= a autor architektonického stylu REST, popisuje výhody a nevýhody jednotlivých architektonických principů ve své disertační práci Architectural Styles and the Design of Network-based Software Architectures z roku 2000 v kapitole 5, kde principy RESTu odvozuje na základě známých přístupů k architektuře.

Rozhraní REST je použitelné pro jednotný a snadný přístup ke zdrojům . Zdrojem mohou být data, stejně jako stavy aplikace (pokud je lze popsat konkrétními daty). +more REST je tedy na rozdíl od známějších [[XML-RPC][Počítačová věda|počítačových věd]], cesta, jak jednoduše vytvořit, číst, aktualizovat (editovat) nebo smazat informace ze serveru pomocí jednoduchých HTTP volání. Jde o obecně přijímaný příklad (paradigma) softwarové architektury distribuovaných systémů, zejména webových služeb. REST je abstrakce struktury a chování World Wide Webu. Cílem REST je vytvořit architektonický styl, který lépe splňuje požadavky moderního webu.

Šest požadavků (zásad, charakteristik, také architektonických principů) kladených na architektonický styl vyhovující paradigmatu REST:

* klient-server - klient a server jsou nezávislí * bezestavový - server stav klienta nezaznamenává * ukládání do mezipaměti - server označuje data ukládaná do mezipaměti * jednotné rozhraní - server vystavuje klientovi prostředky jednotným a předvídatelným způsobem * vícevrstvý systém - prostředníci mezi klientem a serverem chování neovlivňují

a volitelný

* kód na vyžádání - server klientovi může přidat další funkce tím, že mu pošle kód, který může tento klient spustit

Především požadavek na jednotné rozhraní odlišuje paradigma REST od ostatních architektonických stylů. Jakým způsobem musí být tyto zásady prováděny, stanoveno není.

Roy Fielding, jeden z hlavních autorů specifikace[/url]] či SOAP, orientován datově, nikoli procedurálně. Všechny zdroje mají vlastní identifikátor URI a REST definuje také čtyři základní metody pro přístup k nim překrývající se s funkcemi CRUD, pro vytváření , čtení , aktualizaci a mazání .

Historie a použití

Architektonický styl REST byl vyvinut souběžně s protokolem HTTP/1. 1 na základě stávajícího návrhu HTTP/1. +more REST je druhem softwarové architektury navržený pro „hypermediové“ systémy, jako je např. WWW (world wide web). Jako takový není stavěn jen pro webové služby. REST v nejdůslednějším slova smyslu definuje sbírku principů síťové architektury, která popisuje, jak jsou zdroje definovány a adresovány. Ve volnějším slova smyslu je popisován jednoduchým rozhraním, které přenáší doménově specifikovaná data pomocí protokolu HTTP bez přidané zprávové vrstvy, jakou je např. SOAP či HTTP cookies. Tyto dva významy mohou být v rozporu a stejně tak se mohou ve svém významu překrývat. Je možné navrhnout síť s architekturou REST bez použití HTTP a bez interakce s WWW, ale také je možné navrhnout jednoduché rozhraní XML a HTTP, které se plně neřídí principy REST, namísto toho sleduje model RPC. Tyto rozdíly v použití termínu REST způsobují jistý zmatek v technických dokumentacích, proto systémy, které používají principy Fieldingova REST, se označují jako RESTful.

Koncept

Representational State Transfer (REST) je koncept pro design distribuované architektury. Distribuovaná architektura v tomto smyslu znamená, že části programu běží na různých strojích a pro svoji komunikaci využívají síť. +more Pod programem si můžete představit například webovou aplikaci, kde internetový prohlížeč komunikuje s webovým serverem, aplikaci pro výměnu dat mezi finančními institucemi, kde dochází k vzájemnému volání mezi servery.

Základní principy RESTu

stav aplikace a chování je vyjádřen takzvaným resourcem (klíčová abstrakce), každý resource musí mít unikátní identifikátor (URL, URN) * HATEOAS (= Hypermedia as the Engine of Application State, v překladu Hypermedia jako aplikační stav) - stav aplikace je určen pomocí URL. Další možné stavy můžeme získat pomocí odkazů, které klient dostane v odpovědi od serveru. +more * je definován jednotný přístup pro získání a manipulaci s resourcem v podobě čtyř operací CRUD (Create, Read, Update, Delete) * resource může mít různé reprezentace (XML, HTML, JSON, SVG, PDF), klient nepracuje přímo s resource, ale s jeho reprezentací.

Komunikační protokol

client/server - slouží k oddělení odpovědností * bezestavovost (stateless)- každý požadavek musí obsahovat všechny informace nutné k jeho vykonání * cache - každý požadavek může být explicitně označený jako cacheovatelný či necacheovatelný, to umožňuje transparentně zvýšit výkonnost přidáním cache mezi klientem a serverem * Code-On-Demand - funkcionalita klienta může být rozšířena kódem, který zašle server (například JavaScript) * vrstevnatost - umožňuje skládání vrstev poskytujících služby za účelem zvýšení variabilnosti (cache, transformace, rozložení zátěže atd.)

Existují samozřejmě i další přístupy k řešení distribuované architektury jako Remote Procedure Call (RPC). Obecně můžeme říci, že rozdíl mezi RESTem a RPC je ve dvou rovinách, sémantice operací a tím co se distribuuje. +more Sémantika operací v RESTu je konečná a tvoří ji pouze CRUD (create, read, update, delete) na daném resourcu. Oproti tomu v RPC sémantika odpovídá metodám, které jsou volány. V RESTU se distribuuje stav (data představovaná resourcem), oproti chování, které se distribuuje v RPC.

Vlastnosti metod

Následující tabulka ukazuje, jak jsou typicky vlastnosti HTTP implementovány v podobě webové služby:

Formáty REST výměny dat

REST používá pro svou datovou výměnu několik jednoduchých standardizovaných formátů: * ATOM/RSS: velmi populární sada protokolů pro publikaci a aktualizaci informačních zdrojů * JSON (JavaScript Object Notation): speciální záznam popisu dat odvozený z JavaScriptu s nízkou provozní režií, snadno a rychle interpretovatelný v jakémkoliv prohlížeči

Výhody a nevýhody REST oproti RPC

Výhody konceptu REST

jednoduché a změnám odolné rozhraní - snadná rozšiřitelnost * malé nároky na klienta z hlediska porozumění sémantice operací * transparentnost - resource lze na „cestě“ velice snadno cacheovat, transformovat atd.

Nevýhody konceptu REST oproti RPC

Chybějící podpora na úrovní middleware je asi největším problémem, protože vede k velkému nepohodlí při práci s REST. Samozřejmě existují výjimky jako Google a jeho GData [https://developers. +moregoogle. com/gdata], pomocí kterých je využívání služeb Google přes REST pohodlné. GData mají klientské knihovny pro Java, JavaScript, . NET, PHP, C++ a Python. (3).

Odkazy

Reference

Související články

Slug

Externí odkazy

V tomto článku byl použit text z článku [url=https://dagblog. cz/a-rest-c5156313d79e]A REST[/url] na blogu dagblog. +morecz, který je dostupný pod licencí CC-BY 4. 0 International * [url=http://www. ibm. com/developerworks/webservices/library/ws-restful]RESTful Web services: The basics[/url] * [url=http://jt. dev. java. net/files/documents/5553/149793/distributedModel. pdf]Messaging Design Pattern and transparent access to distributed components and services[/url] * [url=https://web. archive. org/web/20070428172836/http://astoria. mslivelabs. com/]"Microsoft ADO. NET Data Services (formerly Project Codename Astoria) for REST"[/url] * [url=https://web. archive. org/web/20100917144034/http://cloudstoragestrategy. com/2009/11/understanding-cloud-storage-apis. html]"Understanding Cloud Storage APIs: Standards, Functions, Lock-in, and What's Next"[/url] * [url=http://www. infoq. com/minibooks/emag-03-2010-rest]"InfoQ Explores: REST"[/url] * [url=http://tomayko. com/writings/rest-to-my-wife]"Grasp the concepts of REST with this fictional dialogue"[/url].

Kategorie:Cloud computing Kategorie:Softwarová architektura Kategorie:Web 2. +more0 Kategorie:HTTP.