REST

A REST (Representational State Transfer) szoftverarchitektúra típus, elosztott kapcsolat (loose coupling), nagy, internet alapú 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

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ó

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ó általában 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étegbeli 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

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

A fentiekkel szemben a SOAP RPC protokoll arra ösztönzi az alkalmazásfejlesztőket, hogy új és önkényes főnév- és igeszó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

Egy REST architektúra a következő hat megszorításnak kell megfeleljen, 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
Az állapotmentesség egy olyan kommunikációs protokoll, amiben a kérést fogadó szerver nem tárol el adatot a kliensről. A kliens-szerver kommunikáció állapotmentes az által, hogy 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, valamint tovább fokozza a skálázhatóságot.
Gyorsítótárazhatóság
Mint ahogy a világhálón, a kliensek és a közvetítők képesek gyorsítótárazni a válaszokat. A válaszoknak ezért közvetlenül vagy közvetve 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 implementált gyorsítótár lehetővé teszi, hogy teljesen megkerüljünk egyes kliens-szerver interakciókat, ezzel megnövelve 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 közvetlen 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ással é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 kliens-szerver interfész alapvető a RESTful rendszerek tervezéséhez. Egyszerűsíti és elválasztja az architektúrát. Ezáltal 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

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.

Jegyzetek

  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. [2009. november 11-i dátummal az eredetiből archiválva]. (Hozzáférés: 2011. május 3.)
  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

Külső referencia

Külső hivatkozások