Budování webových služeb způsobem REST

Original page: http://xfront.com/REST-Web-Services.html

Roger L. Costello

Nejprve poskytnu stručný úvod do REST a poté popíšu, jak budovat webové služby ve stylu REST.

Co je REST?

REST je termín, který vytvořil Roy Fielding ve svém Ph.D. disertační práce [1] k popisu stylu architektury síťových systémů. REST je zkratka pro reprezentativní státní převod.

Proč se tomu říká Representation State Transfer?

Web se skládá ze zdrojů. Zdroj je jakákoliv položka zájmu. Například Boeing Aircraft Corp může definovat zdroj 747. Klienti mohou k tomuto zdroji přistupovat pomocí této adresy URL:

http://www.boeing.com/aircraft/747

Reprezentace ze zdroje je vrácena (např Boeing747.html). Reprezentace umístí klientskou aplikaci do stavu. Výsledkem toho, že klient projde hypertextovým odkazem v Boeing747.html, je přístup k dalšímu zdroji. Nová reprezentace umístí klientskou aplikaci do ještě jiného stavu. Klientská aplikace tedy mění (přenosy) stav s každou reprezentací prostředků –> Přenos reprezentativního stavu!

Zde je vysvětlení Roye Fieldinga o významu reprezentativního převodu státu:

„Representational State Transfer má vyvolat představu, jak se dobře navržená webová aplikace chová: síť webových stránek (virtuální stavový stroj), kde uživatel postupuje aplikací výběrem odkazů (přechodů stavů), což má za následek další stránka (představující další stav aplikace) je přenesena k uživateli a vykreslena pro jeho použití.”

Motivace pro REST

Motivací pro REST bylo zachytit vlastnosti webu, díky kterým byl web úspěšný. Následně se tyto vlastnosti používají k vedení vývoje webu.

REST – architektonický styl, nikoli standard

REST není standard. Neuvidíte, že W3C vydává specifikaci REST. Neuvidíte IBM, Microsoft nebo Sun prodávat vývojářskou sadu nástrojů REST. Proč? Protože REST je jen architektonický styl. Tenhle styl nemůžeš zkrotit. Můžete to pouze pochopit a navrhnout své webové služby v tomto stylu. (Analogický s architektonickým stylem klient-server. Neexistuje žádný standard klient-server.)

Přestože REST není standard, používá standardy:

  • HTTP
  • URL
  • XML/HTML/GIF/JPEG/atd (Reprezentace zdrojů)
  • text/xml, text/html, image/gif, image/jpeg, atd (MIME Typy)

Klasický REST systém

Web je REST systém! Mnoho z těchto webových služeb, které používáte již mnoho let – služby objednávání knih, vyhledávací služby, online slovníkové služby atd. – jsou webové služby založené na REST. Bohužel jste používali REST, budovali REST služby a ani jste o tom nevěděli.

REST se zabývá “velkým obrazem” webu. Nezabývá se detaily implementace (např. používání Java servletů nebo CGI k implementaci webové služby). Podívejme se tedy na příklad vytvoření webové služby z „velkého obrázku“ REST.

Webové služby skladu dílů

Parts Depot, Inc (fiktivní společnost) nasadila některé webové služby, aby svým zákazníkům umožnila:

  • získat seznam dílů
  • získat podrobné informace o konkrétní části
  • odeslat nákupní objednávku (PO)

Podívejme se, jak je každá z těchto služeb implementována klidným způsobem.

Získejte seznam dílů

Webová služba zpřístupní adresu URL zdroje kusovníku. Klient by například použil tuto adresu URL k získání seznamu dílů:

http://www.parts-depot.com/parts

Všimněte si, že „jak“ webová služba generuje kusovník, je pro klienta zcela transparentní. Klient ví pouze to, že pokud odešle výše uvedenou adresu URL, vrátí se dokument obsahující seznam dílů. Vzhledem k tomu, že implementace je pro klienty transparentní, může Parts Depot upravit základní implementaci tohoto zdroje, aniž by to mělo dopad na klienty. Toto je volné spojení.

Zde je dokument, který klient obdrží:

<?xml version="1.0"?>
<p:Parts xmlns:p="http://www.parts-depot.com" 
         xmlns:xlink="http://www.w3.org/1999/xlink">
      <Part id="00345" xlink:href="http://www.parts-depot.com/parts/00345"/>
      <Part id="00346" xlink:href="http://www.parts-depot.com/parts/00346"/>
      <Part id="00347" xlink:href="http://www.parts-depot.com/parts/00347"/>
      <Part id="00348" xlink:href="http://www.parts-depot.com/parts/00348"/>
</p:Parts>

[Předpokládejme, že prostřednictvím vyjednávání obsahu služba určila, že klient chce reprezentaci ve formátu XML (pro zpracování mezi stroji).] Všimněte si, že seznam součástí obsahuje odkazy na získání podrobných informací o každé součásti. Toto je klíčová vlastnost REST. Klient přechází z jednoho stavu do druhého tak, že prozkoumá a vybere z alternativních adres URL v dokumentu odpovědi.

Získejte podrobná data dílů

Webová služba zpřístupňuje URL pro každý zdroj součásti. Zde je příklad, jak klient požaduje část 00345:

http://www.parts-depot.com/parts/00345

Zde je dokument, který klient obdrží:

<?xml version="1.0"?>
<p:Part xmlns:p="http://www.parts-depot.com"   
        xmlns:xlink="http://www.w3.org/1999/xlink">
      <Part-ID>00345</Part-ID>
      <Name>Widget-A</Name>
      <Description>This part is used within the frap assembly</Description>
      <Specification xlink:href="http://www.parts-depot.com/parts/00345/specification"/>
      <UnitCost currency="USD">0.10</UnitCost>
      <Quantity>10</Quantity>
</p:Part>

Znovu pozorujte, jak jsou tato data propojena s dalšími daty – specifikaci této části lze nalézt procházením hypertextového odkazu. Každý dokument s odpovědí umožňuje klientovi procházet a získat podrobnější informace.

Odeslat PO

Webová služba zpřístupňuje adresu URL pro odeslání objednávky. Klient vytvoří dokument instance PO, který odpovídá schématu PO, které Parts Depot navrhl (a zveřejnil v dokumentu WSDL). Klient odešle PO.xml jako datovou část HTTP POST.

Služba PO odpoví na HTTP POST s URL na odeslanou PO. Klient tak může objednávku kdykoli poté načíst (pro aktualizaci/editaci). PO se stala informací, která je sdílena mezi klientem a serverem. Sdíleným informacím (PO) je přidělena adresa (URL) serverem a jsou vystaveny jako webová služba.

Logické adresy URL versus fyzické adresy URL

Zdroj je koncepční entita. Reprezentace je konkrétním projevem zdroje. Tato adresa URL:

http://www.parts-depot.com/parts/00345

je logická adresa URL, nikoli fyzická adresa URL. Není tedy třeba, aby pro každou část byla například statická HTML stránka. Ve skutečnosti, pokud by existoval milion částí, pak by milion statických HTML stránek nebyl příliš atraktivní design.

[Podrobnosti implementace: Parts Depot by mohl implementovat službu, která získává podrobná data o konkrétním dílu pomocí Java Servlet, který analyzuje řetězec za názvem hostitele, používá číslo dílu k dotazu na databázi dílů, formuluje výsledky dotazu jako XML a pak vraťte XML jako datovou část odpovědi HTTP.]

Pokud jde o styl, adresy URL by neměly odhalovat použitou techniku implementace. Musíte mít možnost svou implementaci změnit, aniž byste ovlivnili klienty nebo měli zavádějící adresy URL.

Charakteristika webových služeb REST

Zde jsou vlastnosti REST:

  • Klient-Server: styl interakce založený na stahování: náročné reprezentace vytažení komponent.
  • Bezstavový: každý požadavek od klienta k serveru musí obsahovat všechny informace nezbytné k pochopení požadavku a nemůže využívat žádný uložený kontext na serveru.
  • Cache: pro zlepšení efektivity sítě musí být možné odezvy označit jako cacheable nebo non-cacheable.
  • Jednotné rozhraní: ke všem zdrojům se přistupuje pomocí obecného rozhraní (např. HTTP GET, POST, PUT, DELETE).
  • Pojmenované zdroje – systém se skládá ze zdrojů, které jsou pojmenovány pomocí URL.
  • Vzájemně propojené reprezentace zdrojů – reprezentace zdrojů jsou vzájemně propojeny pomocí URL, což umožňuje klientovi postupovat z jednoho stavu do druhého.
  • Mezi klienty a zdroje lze vložit vrstvené komponenty – prostředníky, jako jsou proxy servery, cache servery, brány atd., aby podpořili výkon, bezpečnost atd.

Principy návrhu webových služeb REST

1. Klíčem k vytvoření webových služeb v síti REST (tj. webu) je identifikovat všechny koncepční entity, které chcete vystavit jako služby. Výše jsme viděli několik příkladů zdrojů: seznam dílů, podrobná data dílů, nákupní objednávka.

2. Vytvořte URL pro každý zdroj. Zdrojem by měla být podstatná jména, nikoli slovesa. Nepoužívejte například toto:

http://www.parts-depot.com/parts/getPart?id=00345

Všimněte si slovesa, getPart. Místo toho použijte podstatné jméno:

http://www.parts-depot.com/parts/00345

3. Rozdělte své zdroje do kategorií podle toho, zda klienti mohou pouze obdržet reprezentaci zdroje, nebo zda klienti mohou zdroj upravit (přidat k němu). V prvním případě zpřístupněte tyto prostředky pomocí HTTP GET. Pro pozdější zpřístupnění těchto zdrojů pomocí HTTP POST, PUT a/nebo DELETE. 4. Všechny zdroje dostupné přes HTTP GET by měly být bez vedlejších efektů. To znamená, že zdroj by měl pouze vracet reprezentaci zdroje. Vyvolání prostředku by nemělo vést k úpravě prostředku. 5. Žádný muž/žena není ostrov. Stejně tak by žádná reprezentace neměla být ostrovem. Jinými slovy, umístěte hypertextové odkazy do reprezentací zdrojů, abyste klientům umožnili získat další informace a/nebo získat související informace.6. Navrhněte postupné odhalování dat. Neodhalujte vše v jediném dokumentu s odpovědí. Chcete-li získat další podrobnosti, zadejte hypertextové odkazy. 7. Zadejte formát dat odezvy pomocí schématu (DTD, W3C Schema, RelaxNG nebo Schematron). U služeb, které vyžadují POST nebo PUT, poskytněte také schéma pro určení formátu odpovědi. 8. Popište, jak mají být vaše služby vyvolány pomocí dokumentu WSDL nebo jednoduše dokumentu HTML.

Souhrn

Tento článek popsal REST jako architektonický styl. Ve skutečnosti je to architektonický styl webu. REST popisuje, proč web dobře funguje. Dodržování zásad REST zajistí, že vaše služby budou dobře fungovat v kontextu webu. V příštím článku budu psát o vývoji webu pomocí principů REST.

Potvrzení

Děkuji Robertu Leftwichovi a Philipu Eskelinovi za velmi užitečné komentáře při vytváření tohoto dokumentu.

Reference

[1] http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm

Leave a Reply

Your email address will not be published. Required fields are marked *