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]
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.
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]
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 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.
Wikiwand in your browser!
Seamless Wikipedia browsing. On steroids.
Every time you click a link to Wikipedia, Wiktionary or Wikiquote in your browser's search results, it will show the modern Wikiwand interface.
Wikiwand extension is a five stars, simple, with minimum permission required to keep your browsing private, safe and transparent.
