REST

A Wikipédiából, a szabad enciklopédiából

A REST (Representational State Transfer) egy szoftverarchitektúra típus elosztott hipermédia rendszerek számára, amilyen például a világháló. A Representational State Transfer kifejezést Roy Fielding vezette be és definiálta 2000-ben a doktori disszertációjában.[1][2] Fielding egyike a HTTP (HyperText Transfer Protocol) specifikáció szerkesztőinek.[3][4]

Azokat a rendszereket, amelyek eleget tesznek a REST megszorításainak, "RESTful"-nak nevezik.[5]

Történet[szerkesztés | forrásszöveg szerkesztése]

A REST architektúra típust párhuzamosan fejlesztették a HTTP specifikáció 1.1-es változatával, a már meglévő HTTP 1.0-ás specifikáció dizájnjára alapozva.[6] A legnagyobb olyan rendszer, amely eleget tesz a REST szoftverarchitektúra típus követelményeinek a világháló. A REST szemlélteti a világháló architektúráját azzal, hogy leírja és megköti a világháló négy komponensének (kiszolgálók, átjárók, proxyk és kliensek) magas szintű kölcsönhatásait.

Koncepció[szerkesztés | forrásszöveg szerkesztése]

Egy REST típusú architektúra kliensekből és szerverekből áll. A kliensek kéréseket indítanak a szerverek felé; a szerverek kéréseket dolgoznak fel és a megfelelő választ küldik vissza. A kérések és a válaszok erőforrás-reprezentációk szállítása köré épülnek. Az erőforrás lényegében bármilyen koherens és értelmesen címezhető koncepció lehet. Egy erőforrás-reprezentáció tipikusan egy dokumentum, mely rögzíti az erőforrás jelenlegi vagy kívánt állapotát.

Bármely adott pillanatban egy kliens vagy állapotok közötti átmenetben van, vagy "nyugalmi" állapotban. A nyugalmi állapotban lévő kliens képes interakcióra a felhasználójával, de nem hoz létre terhelést és nem fogyaszt tárolót a szervereken vagy a hálózaton.

Ha a kliens készen áll az átmenetre egy új állapotba, akkor elkezdi küldeni a kéréseit a szerverekhez. Míg legalább egy olyan kérés van, amelyre nem érkezett válasz, a kliens átmeneti állapotban marad. Egyes erőforrás-reprezentációk hivatkozásokat tartalmaznak további erőforrásokra, amelyeket a kliens felhasználhat új állapotba történő átmenetkor.[7]

A REST eredetileg a HTTP keretein belül lett leírva, de nem korlátozódik erre a protokollra. Egy "RESTful" architektúra más alkalmazási réteg protokollra is épülhet, amennyiben az már rendelkezik értelmes erőforrás-reprezentáció átvitelhez szükséges gazdag és egységes szókinccsel. A "RESTful" alkalmazások maximálisan kihasználják a választott hálózati protokoll már létező, jól kialakított interfészeit és egyéb beépített képességeit, és minimalizálják új alkalmazás-specifikus jellemzők bevezetését.

A HTTP példája[szerkesztés | forrásszöveg szerkesztése]

A HTTP nagyon gazdag szókinccsel rendelkezik igék (vagy "metódusok"), URI-k, média típusok, kérés- és feleletkódok stb. szempontjából. Egy REST alkalmazás a HTTP protokoll meglévő tulajdonságait használja és így lehetővé teszi a proxyknak és az átjáróknak, hogy együttműködjenek az alkalmazással (például gyorsítótárazás vagy biztonsági funkciók formájában).

A SOAP példája[szerkesztés | forrásszöveg szerkesztése]

A fentiekkel szemben a SOAP RPC protokoll arra ösztönzi az alkalmazásfejlesztőket, hogy új és önkényes főnév és ige szókincset definiáljanak (például getUsers(), savePurchaseOrder(...)) és csak a POST HTTP-igét használják. Emiatt sok létező HTTP képesség nincs kihasználva (pl. gyorsítótárazás, autentikáció).[8]

Megszorítások[szerkesztés | forrásszöveg szerkesztése]

Egy REST architektúra a következő hat megszorításnak kell megfelelnie, miközben az egyes komponensek implementációit hagyja szabadon tervezni:

Kliens-szerver architektúra
A kliensek el vannak különítve a szerverektől egy egységes interfész által. Az érdekeltségek ilyen nemű szétválasztása azt jelenti, például, hogy a kliensek nem foglalkoznak adattárolással, ami a szerver belső ügye marad, és így a kliens kód hordozhatósága megnő. A szerverek nem foglalkoznak a felhasználói felülettel vagy a kliens állapotával, így a szerverek egyszerűbbek és még skálázhatóbbak lehetnek. A szerverek és kliensek áthelyezhetőek és fejleszthetőek külön-külön is, egészen addig amíg az interfész nem változik meg.
Állapotmentesség
A kliens-szerver kommunikáció tovább korlátozott az által, hogy a szerveren nem tárolják a kliens állapotát a kérések között. Minden egyes kérés bármelyik klienstől tartalmazza az összes szükséges információt a kérés kiszolgálásához, és minden állapotot a kliens tárol. A szerver lehet állapottartó; ez a korlátozás csupán azt követeli meg, hogy a szerver oldali erőforrás-állapotok URL által címezhetőek legyenek. Ez nem csak a szerver felügyeletét teszi lehetővé, de megbízhatóbbá teszi őket a hálózati meghibásodásokkal szemben, valamit tovább fokozza a skálázhatóságot.
Gyorsítótárazhatóság
Mint ahogy a világhálón, a kliensek itt is képesek gyorsító-tárazni a válaszokat. A válaszoknak ezért impliciten vagy expliciten tartalmazniuk kell, hogy gyorsítótárazhatóak-e vagy sem. Így elkerülhető, hogy a kliens téves vagy elavult adatokat használjon fel újra. Egy jól menedzselt gyorsítótár lehetővé teszi, hogy teljesen megkerüljünk egyes kliens-szerver interakciókat, továbbá megnöveli a rendszer skálázhatóságát és a teljesítményét.
Réteges felépítés
Egy kliens általában nem tudja megmondani, hogy direkt csatlakozott-e a végpont szerverhez, vagy közvetítő segítségével. A közvetítő szerverek megnövelhetik a rendszer skálázhatóságát terheléseloszlás kiegyenlítéssel és megosztott gyorsítótárak használatával.
Igényelt kód (opcionális)
A szerverek képesek időlegesen kiterjeszteni vagy testre szabni egy kliens funkcionalitását, programrészek átadásával, amelyeket a kliens futtatni képes. Ide tartoznak az előre fordított komponensek (pl. Java appletek) és a kliensoldali szkriptek (pl. JavaScript).
Egységes interfész
Az egységes interfész kliens és szerver között egyszerűsíti és kettéválasztja az architektúrát, és lehetővé teszi, hogy egymástól függetlenül fejlődjenek az egyes részek. Az interfész négy irányadó elve alább kerül részletezésre.

A REST architektúra egyetlen opcionális megszorítása az igényelt kód. Ha egy szolgáltatás sért bármely más megszorítást, azt nem lehet feltétlenül "RESTful"-nak nevezni.

Ha az architektúra teljesíti ezeket a korlátozásokat, akkor rendelkezni fog az elosztott hipermédia rendszerek kiemelkedő tulajdonságaival, mint például a teljesítmény, skálázhatóság, egyszerűség, módosíthatóság, láthatóság, hordozhatóság és megbízhatóság.

Az interfész vezérelvei[szerkesztés | forrásszöveg szerkesztése]

Az egységes interfész, melyet minden REST interfésznek biztosítania kell, alapvetőnek tekinthető minden REST szolgáltatás tervezésekor.[8]

Erőforrások azonosítása
Egyéni erőforrások azonosítása a kérésekben történik, például URI-k használatával HTTP-alapú REST rendszereknél. A források maguk koncepcionálisan elkülönítettek a reprezentációktól, melyeket a kliens kap. Például a szerver nem küldi el az adatbázisát, hanem néhány HTML, XML vagy JSON dokumentumot, melyek az adatbázis néhány rekordját reprezentálják, UTF-8-ban kódolva, a kérés adataitól és a szerver implementációjától függően.
Erőforrások manipulációja ezeken a reprezentációkon keresztül
Ha egy kliens rendelkezik egy erőforrás-reprezentációval, beleértve minden csatolt metaadatot, akkor elegendő információja van az erőforrás módosításához vagy törléséhez a szerverről, feltéve, ha van engedélye hozzá.
Önleíró üzenetek
Minden egyes üzenet elegendő információt tartalmaz az üzenet feldolgozásához. Például a média típusát, hogy a kliens tudja, hogyan jelenítse meg az erőforrást.[1]
Hipermédia, mint az alkalmazásállapot motorja
A kliensek csakis azokon az állapotokon mehetnek át, amelyeket a szerver által küldött hipermédia tartalmaz hivatkozások alakjában. Pár egyszerű belépési pont kivételével a kliens nem feltételezi egyik művelet meglétét sem.

Források[szerkesztés | forrásszöveg szerkesztése]

  1. ^ a b Fielding disszertációjában az 5. fejezet címe "Representational State Transfer (REST)".
  2. Fielding magyarázata a REST jelentéséről
  3. RFC 1945
  4. RFC 2616
  5. Richardson, Leonard, Sam Ruby. Preface, RESTful web service. O'Reilly Media (2007). ISBN 978-0-596-52926-0. Hozzáférés ideje: 2011. január 18. 
  6. Fielding a REST fejlesztéséről mesél
  7. Fielding az alkalmazásállapotokat taglalja
  8. ^ a b Scribner, Kenn & Seely, Scott (2009), Effective REST Services via .NET, Boston: Addison-Wesley, ISBN 978-0-321-61325-7

Lásd még[szerkesztés | forrásszöveg szerkesztése]

Külső referencia[szerkesztés | forrásszöveg szerkesztése]

Fielding, Roy T. & Taylor, Richard N. (2002-05), "Principled Design of the Modern Web Architecture", ACM Transactions on Internet Technology (TOIT) (New York: Association for Computing Machinery) 2 (2): 115–150, ISSN 1533-5399, doi:10.1145/514183.514185, <http://www.ics.uci.edu/~taylor/documents/2002-REST-TOIT.pdf>

Fielding, Roy Thomas (2000), Architectural Styles and the Design of Network-based Software Architectures, University of California, Irvine, <http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm>

Pautasso, Cesare; Zimmermann, Olaf & Leymann, Frank (2008-04), "RESTful Web Services vs. Big Web Services: Making the Right Architectural Decision", 17th International World Wide Web Conference (WWW2008) (Beijing, China), <http://www.jopera.org/docs/publications/2008/restws>

Richardson, Leonard & Ruby, Sam (2007-05), RESTful Web Services, O'Reilly, ISBN 978-0-596-52926-0, <http://oreilly.com/catalog/9780596529260>

Külső hivatkozások[szerkesztés | forrásszöveg szerkesztése]