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).

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.

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.

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

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

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

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

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

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)

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

• Slug

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

• RESTful Web services: The basics
• Messaging Design Pattern and transparent access to distributed components and services^{[nedostupný zdroj]}
• "Microsoft ADO.NET Data Services (formerly Project Codename Astoria) for REST"
• "Understanding Cloud Storage APIs: Standards, Functions, Lock-in, and What's Next"
• "InfoQ Explores: REST"
• "Grasp the concepts of REST with this fictional dialogue"