A REST ( reprezentációs állapotátvitel ) a szoftverarchitektúra olyan stílusa, amely meghatározza a webszolgáltatások létrehozásához használandó korlátozások halmazát . A REST architektúra stílusú webszolgáltatások, más néven RESTful webszolgáltatások , interoperabilitást hoznak létre az interneten lévő számítógépek között . A REST webszolgáltatások lehetővé teszik a kérelmező rendszereknek, hogy a webes erőforrásokat szöveges ábrázolásukon keresztül egységes, előre meghatározott hontalan műveletek révén manipulálják . Más típusú webszolgáltatások, például SOAP webszolgáltatások leleplezik saját önkényes műveleteiket.
A webes erőforrásokat először a világhálón határozták meg URL- ként azonosított dokumentumokként vagy fájlokként . Ma azonban sokkal általánosabb és elvontabb definíciójuk van, amely bármit vagy entitást tartalmaz, amely az interneten azonosítható, megnevezhető, címezhető vagy valamilyen módon kezelhető. A REST webszolgáltatásban az erőforrás URI-hoz intézett kérések olyan választ adnak, amelynek törzsét HTML , XML , JSON vagy valamilyen más formátumban formázzák. A válasz megerősítheti, hogy a tárolt erőforrás sérült, és hiperhivatkozásokat adhat más kapcsolódó erőforrásokhoz vagy erőforrások gyűjtéséhez. A HTTP protokoll használatakor, amint az gyakran előfordul, a rendelkezésre álló HTTP módszerek : GET, HEAD, POST, PUT, PATCH, DELETE, CONNECT, OPTIONS és TRACE.
A hontalan protokollok és a szokásos műveletek használatával a REST rendszerek az érzékenységre, a megbízhatóságra és a skálázhatóságra törekszenek, olyan komponensek újrafelhasználásával, amelyek kezelhetők és frissíthetők anélkül, hogy hosszú távon is befolyásolnák a teljes rendszert.
A reprezentációs állapottranszfer kifejezést Roy Fielding először 2000-ben határozta meg doktori értekezésének 5. fejezetében . Fielding tézise elmagyarázta a REST alapelveit, amelyek 1994 óta korábban "HTTP objektum modell" néven ismertek, és amelyeket a HTTP 1.1 és URI szabványok fejlesztésében használtak. A kifejezés arra utal, hogy egy jól megtervezett webalkalmazás hogyan viselkedik: ez egy erőforrások hálózata (virtuális állapotgép), amelyen belül a felhasználó erőforrás-azonosítók, például http: //www.example .com / articles kiválasztásával mozog. / 21 és erőforrás-műveletek, például a GET vagy a POST (alkalmazásállapot-átmenetek), amelyek a következő erőforrás (az új alkalmazásállapot) ábrázolását továbbítják a használandó felhasználónak.
Roy Fielding meghatározott REST, 2000-ben doktori értekezését Építészeti stílusok és a Design Network-alapú szoftver architektúrák a University of California, Irvine . Ott fejlesztette ki a REST architektúra stílusát a HTTP 1.1 protokoll mellett 1996-tól 1999-ig, a meglévő 1996-os HTTP 1.0 modell alapján.
A REST fejlődésének visszatekintő pillantásában Fielding elmondta:
Az egész HTTP szabványosítási folyamat során felkértek, hogy védjem meg a web tervezési lehetőségeit. Ez rendkívül bonyolult dolog egy olyan folyamaton belül, amely bárki javaslatát elfogadja egy olyan témában, amely gyorsan egy egész iparág központjává vált. Jóval több mint 500 fejlesztőtől érkeztek észrevételek, akik közül sokan évtizedes tapasztalattal rendelkező kiváló mérnökök voltak, és mindent el kellett magyaráznom, a webes interakció legelvontabb fogalmaitól kezdve a HTTP-szintaxis legfinomabb részleteihez. Ez a folyamat csiszolta a modellemet az alapelvek, tulajdonságok és korlátozások alapvető készletére, amelyeket ma REST-nek hívnak.
„A HTTP szabványosítási folyamat során felkértek, hogy védjem meg a web építészeti döntéseit. Rendkívül bonyolult feladat, mivel az eljárás során bárki beadványokat fogad el olyan témában, amely gyorsan egy egész iparág középpontjába került. Több mint 500 fejlesztőtől kaptam visszajelzést, akik közül sokan évtizedes tapasztalattal rendelkező neves mérnökök voltak, és mindent meg kellett magyaráznom, a webes interakciók legelvontabb fogalmaitól kezdve a webszintaxis finomabb részletein keresztül. Ez az eljárás a modellemet egy olyan alapelvekre, tulajdonságokra és korlátozásokra redukálta, amelyeket ma REST-nek hívnak. "
Hat építészeti korlát meghatározza a REST rendszert. Ezek a korlátozások korlátozzák, hogy a kiszolgáló hogyan tudja feldolgozni és reagálni az ügyfél kéréseire, így a korlátok között cselekedve a rendszer kívánatos nem funkcionális tulajdonságokat nyer, például teljesítményt, méretezhetőséget, egyszerűséget, méretezhetőséget stb. Az a rendszer, amely megsérti ezen korlátok egyikét, nem tekinthető úgy, hogy betartja a REST architektúrát.
A felelősség el van osztva az ügyfél és a szerver között. A felhasználói felület és az adattárolás leválasztása javítja a felhasználói felület több platformon történő hordozhatóságát. A rendszer méretezhetőségét javítja a szerver összetevőinek egyszerűsítése is. De az internet számára talán még elengedhetetlenebb, hogy a szétválasztás lehetővé teszi az alkatrészek önálló fejlődését, ezáltal támogatva az internet méretezéséhez szükséges több szervezeti tartományt.
Az ügyfél - szerver kommunikáció anélkül zajlik, hogy két egymást követő kérés között megtartaná a kommunikációs munkamenet állapotát a szerveren. A munkamenet állapotát az ügyfél őrzi és továbbítja minden új kéréssel. Az ügyfélkérelmek tehát tartalmaznak minden olyan információt, amelyre a szerver válaszolhat. Az összetevők közötti kölcsönhatások láthatósága javult, mivel a kérések teljesek. A kudarc toleranciája is nagyobb. Ezenkívül az a tény, hogy nem kell állandó kapcsolatot fenntartani az ügyfél és a szerver között, lehetővé teszi a kiszolgáló számára, hogy válaszoljon más ügyfelek egyéb kéréseire az összes kommunikációs port telítettsége nélkül, ami javítja a rendszer skálázhatóságát.
Ennek a hontalan módnak a szokásos kivétele azonban az ügyfél-hitelesítés kezelése, így az utóbbinak nem kell minden információt visszaküldenie minden egyes kérésének.
Az ügyfelek és a köztes szerverek gyorsítótárazhatják a válaszokat. A válaszokat tehát hallgatólagosan vagy kifejezetten gyorsítótárazhatóként kell definiálni, hogy megakadályozzuk az ügyfeleket abban, hogy a későbbi kérésekre válaszul elavult vagy nem megfelelő adatokat kapjanak meg. A jól kezelt gyorsítótár részben vagy teljesen kiküszöböli az ügyfél-szerver interakciókat, tovább javítva a rendszer méretezhetőségét és teljesítményét.
Az ügyfél általában nem tudja megmondani, hogy közvetlenül a végkiszolgálóhoz vagy egy köztes szerverhez csatlakozik-e. A közbenső szerverek a terheléselosztás és a megosztott gyorsítótárazás révén javíthatják a rendszer méretezhetőségét. Megerősíthetik a biztonságpolitikát is.
A szerverek ideiglenesen kiterjeszthetik vagy módosíthatják az ügyfél funkcionalitását futtatható kód feltöltésével. Például Java kisalkalmazásokkal vagy JavaScript szkriptekkel . Ez segít az ügyfelek egyszerűsítésében azáltal, hogy csökkenti az alapértelmezés szerint megvalósítandó funkciók számát, és javítja a rendszer méretezhetőségét. Másrészt csökkenti az erőforrás-szervezet láthatóságát is. Ezért választható korlátozást jelent a REST architektúrában.
Az egységes interfész-kényszer alapvető a REST-rendszerek tervezésénél. Leegyszerűsíti és szétválasztja az architektúrát, lehetővé téve az egyes komponensek önálló fejlődését. Az egységes felület négy korlátozása a következő.
Erőforrások azonosítása lekérdezésekben Minden erőforrást a kérésekben azonosítanak, például egy URI egy webalapú REST rendszerek esetén. Maguk az erőforrások fogalmilag megkülönböztetik azokat a reprezentációkat, amelyeket az ügyfélnek visszaadnak. Például a kiszolgáló HTML , XML vagy JSON formátumban küldhet adatokat az adatbázisából , amelyek az erőforrás belső ábrázolásának különböző ábrázolásai. Az erőforrások manipulálása reprezentációkkal Az erőforrások minden ábrázolása elegendő információt nyújt az ügyfél számára az erőforrás módosításához vagy törléséhez. Önleíró üzenetek Minden üzenet elegendő információt tartalmaz annak értelmezéséhez. Például a meghívandó tolmács leírható egy típusú adathordozóval . A Hypermedia mint alkalmazás állapotmotor ( HATEOAS ) Miután elérte az alkalmazás kezdeti URI- ját - hasonlóan ahhoz, mint az emberek egy weboldal kezdőlapjához -, az ügyfélnek képesnek kell lennie arra, hogy dinamikusan használja a szerver által biztosított hiperhivatkozásokat, hogy felfedezze a többi lehetséges műveletet és a böngészés folytatásához szükséges erőforrásokat. Nem szükséges, hogy az ügyfél hardveresen kódolja ezeket az információkat az alkalmazás felépítésével vagy dinamikájával kapcsolatban.A REST építészeti korlátai az őket tiszteletben tartó rendszereknek a következő építészeti tulajdonságokat adják:
A REST kliens - szerver aggályok szétválasztása egyszerűsíti az alkatrészek megvalósítását, csökkenti a csatlakozók szemantikájának összetettségét, javítja a teljesítményhangolás hatékonyságát és növeli a tiszta szerver-összetevők skálázhatóságát. A réteges rendszerkorlátozások lehetővé teszik a közvetítők - proxyk, átjárók és tűzfalak - bevezetését a kommunikáció különböző pontjaiba anélkül, hogy megváltoztatnák az összetevők közötti interfészeket, ezáltal lehetővé téve számukra, hogy segítsenek a kommunikáció fordításában vagy javítsák a teljesítményt nagyméretű, megosztott gyorsítótár segítségével. A REST lehetővé teszi a közbenső feldolgozást az üzenetek korlátozásával, hogy önleíróak legyenek: a kérelmek közötti interakció állapot nélküli, a szemantika jelzésére és az információcserére szabványos módszereket és médiatípusokat használnak, a válaszok pedig kifejezetten a cache-elhetőséget jelzik.
„A kliens-szerver aggályok elkülönítése leegyszerűsíti az alkatrészek megvalósítását, csökkenti a csatlakozók szemantikájának összetettségét, javítja a teljesítményhangolás hatékonyságát és növeli a tiszta szerver-összetevők skálázhatóságát. A réteges architektúra-korlátozás lehetővé teszi a közvetítők - proxy szerverek, átjárók és tűzfalak - különböző szintű bevezetését a kommunikációban anélkül, hogy megváltoztatnák az összetevők közötti interfészeket, ezáltal lehetővé téve számukra, hogy beavatkozhassanak a kommunikáció fordításába, vagy javítsák a teljesítményt nagyméretű gyorsítótár segítségével rendszerek. A REST lehetővé teszi a köztes feldolgozást az önleíró üzenetek kényszerítésével: a kérelmek közötti interakció hontalan, a szemantika és az információcsere szabványos módszereket és médiatípusokat használ, a válaszok pedig kifejezetten a gyorsítótárazás lehetőségét jelzik. "
Az API REST alapú HTTP-t a következők határozzák meg:
Az alábbi táblázat bemutatja, hogy a HTTP-módszereket hogyan használják általában a REST API-ban:
| URI | KAP | POST | PUT | TAPASZ | TÖRÖL |
|---|---|---|---|---|---|
| Erőforrás-gyűjtés, mint pl http://api.exemple.com/collection/ | Lekéri az URI az erőforrás a kollekció tagjait erőforrás a válasz törzse. | Taggyűjteményt hoz létre a gyűjtemény erőforrásában a kérelem törzsében található utasítások felhasználásával. Az URI a létrehozott elem erőforrás automatikusan kap , és visszatért a hely fejléc mezőt a választ. | A gyűjtemény-erőforrás tagerőforrásainak összes reprezentációját lecseréli a kérelem törzsében szereplő ábrázolásra, vagy létrehozza a gyűjteményi erőforrást, ha az nem létezik. | Frissíti a gyűjtemény erőforrás összes tagjának erőforrás-reprezentációját a kérelem törzsében található utasítások felhasználásával, vagy opcionálisan létrehozza a gyűjteményi erőforrást, ha nem létezik. | Eltávolítja a tag erőforrások összes ábrázolását a gyűjtemény erőforrásából. |
| Tag-erőforrás, mint pl http://api.exemple.com/collection/item3 | Letölti a tag erőforrás reprezentációját a válasz testben. | Tag erőforrást hoz létre a tag erőforrásban a kérelem törzsében található utasítások felhasználásával. Az URI a létrehozott elem erőforrás automatikusan kap , és visszatért a hely fejléc mezőt a választ. | A tag erőforrás összes reprezentációját lecseréli , vagy a tag erőforrást létrehozza, ha az nem létezik, a kérelem törzsében szereplő ábrázolással. | Frissíti a tag erőforrás összes reprezentációját, vagy opcionálisan létrehozza a tag erőforrást, ha nem létezik, a kérelem törzsében található utasítások felhasználásával. | Eltávolítja a tag erőforrás összes reprezentációját. |
A GET módszer biztonságos, vagyis hogy egy erőforrásra való alkalmazás nem eredményezi az erőforrás állapotváltozását (csak olvasható szemantika). A GET, PUT és DELETE metódusok idempotensek , vagyis ha többször alkalmazzák őket egy erőforrásra, akkor az erőforrás állapotában ugyanaz a változás következik be, mint az egyszeri alkalmazásban, bár a válasz eltérő lehet. A GET és a POST módszerek gyorsítótárazhatóak , vagyis megengedett a válaszok tárolása ezekre a kérelmekre a későbbi újrafelhasználás céljából.
A SOAP- orientált webszolgáltatásokkal ellentétben a REST API-k számára nincs hivatalos szabvány, mert a REST egy architektúra, míg a SOAP egy protokoll. A REST önmagában nem szabvány, de az ezt az architektúrát követő megvalósítások olyan szabványokat használnak, mint a HTTP , URI , JSON és XML .