Wikipedie

Representational State Transfer

architektura rozhraní pro práci s daty v distribuovaném prostředí
(přesměrováno z REST)
Tento článek potřebuje úpravy.
Můžete Wikipedii pomoci tím, že ho vylepšíte. Jak by měly články vypadat, popisují stránky Vzhled a styl, Encyklopedický styl a Odkazy.

Representational state transfer (REST) je termín z 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:[1][2]

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

a volitelný

  • kód na vyžádání (Code-On-Demand) – server klientovi může přidat další funkce tím, že mu pošle kód, který může tento klient spustit[3]

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 HTTP 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[1] 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 (resources). Zdrojem mohou být data, stejně jako stavy aplikace (pokud je lze popsat konkrétními daty). REST je tedy na rozdíl od známějších XML-RPC č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[2], pro vytváření (Create), čtení (Read), aktualizaci (Update) a mazání (Delete).

Historie a použití editovat

Architektonický styl REST byl vyvinut souběžně s protokolem HTTP/1.1 na základě stávajícího návrhu HTTP/1.0. 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 editovat

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íť. 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 editovat

  • 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.
  • 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 editovat

  • 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. 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 editovat

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

Metody HTTP pro webové služby, jež jsou „RESTful“
Zdroj GET PUT POST DELETE
předpokládané vlastnosti metody bezpečná (0: read only, pouze čtení) idempotentní (1: write once, zápis jen jednou) datově nebezpečná (x: writing, zapisování) idempotentní (1: write once, zápis jen jednou)
URI kolekce, například http://example.com/resources/ Seznam (List) URI a případně další detaily členů kolekce. Vyměnit (Replace) celou kolekci za jinou. Vytvořit (Create) nový záznam do kolekce. Jeho ID je automaticky přiděleno a většinou vráceno touto operací. Smazat (Delete) celou kolekci.
URI prvku, například http://example.com/resources/142 Vrátit (Retrieve) reprezentaci adresovaného členu v kolekci, vyjádřeného vhodným internetovým typem média. Upravit (Update) adresovaný člen kolekce, nebo – pokud neexistuje – vytvořit (create) jej. Jednat s adresovaným členem jako s kolekcí a přidat pod něj novou položku. Smazat (Delete) adresovaný prvek z kolekce.

Formáty REST výměny dat editovat

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 editovat

Výhody konceptu REST editovat

  • 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 editovat

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 [1], 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 editovat

Reference editovat

V tomto článku byl použit překlad textu z článku Representational State Transfer na německé Wikipedii.

  1. ↑ a b FIELDING, Roy Thomas. Architectural Styles and the Design of Network-based Software Architectures. www.ics.uci.edu [online]. University of California, Irvine, 2000 [cit. 2023-01-15]. Dissertation. Dissertation Committee: Professor Richard N. Taylor, Chair Professor Mark S. Ackerman and Professor David S. Rosenblum. Dostupné online. (anglicky) 
  2. ↑ a b BUSH, Thomas. CRUD vs. REST: What's the Difference? | Nordic APIs |. Nordic APIs [online]. 2020-08-25 [cit. 2023-01-15]. Dostupné online. (anglicky) 
  3. ↑ Code on demand (optional) - Building RESTful Web Services with PHP 7 [Book]. www.oreilly.com [online]. [cit. 2023-01-15]. Dostupné online. (anglicky) 

Související články editovat

Externí odkazy editovat

V tomto článku byl použit text z článku A REST na blogu dagblog.cz, který je dostupný pod licencí CC-BY 4.0 International

Citováno z „https://cs.wikipedia.org/w/index.php?title=Representational_State_Transfer&oldid=23678009“