REST: erőforrás, reprezentáció és egységes interfész
Célok
A lecke végére el tudod magyarázni a REST architekturális korlátait, meg tudod különböztetni a REST-szemléletű HTTP API-t a „JSON HTTP fölött” megoldástól, és a hét szempont szerint jellemezni tudod.
Miért kell?
Szolgáltatások között a hívás jelentését és a közös szabályokat meg kell állapítani. A REST nem egy konkrét API-formátum, hanem egy architekturális stílus, amelynek célja, hogy a komponensek egységes, jól megfigyelhető és gyorsítótárazható módon kommunikáljanak. Roy Fielding doktori értekezése írta le.
Mi a REST?
A REST Fielding szerint korlátok halmaza:
kliens–szerver: a felelősségek szétválasztása;
állapotmentesség (stateless): minden kérésnek tartalmaznia kell a megértéséhez szükséges információt;
gyorsítótárazhatóság: a válaszok megjelölik, hogy gyorsítótárazhatók-e;
egységes interfész: erőforrás-azonosítás, az erőforrások kezelése reprezentációkon át, önleíró üzenetek, és a hipermédia mint az alkalmazásállapot motorja;
rétegezett rendszer: a komponensek hierarchikus rétegekből állhatnak;
kód letöltése (code-on-demand): opcionális korlát.
Az erőforrás bármi, amit azonosítani lehet (egy rendelés, egy gyűjtemény). A kliens az erőforrás reprezentációját kapja, nem a belső objektumot vagy adatbázissort. Ugyanaz az erőforrás több formátumban is megjelenhet; a Content-Type és az elfogadott formátumokról szóló megállapodás teszi értelmezhetővé.
sequenceDiagram
participant K as Kliens
participant S as Szerver
K->>S: GET /orders/42 (Accept: application/json)
S-->>K: 200, az erőforrás JSON-reprezentációja
Metódusok és szándék
Az RFC 9110 alapján a GET olvasási szándékú, biztonságos és idempotens; a PUT és a DELETE idempotens; a POST az erőforráshoz kötődő feldolgozást kér, nem idempotens. A biztonságos metódus ismétlése vagy előzetes betöltése nem kell hogy üzleti változást okozzon, ezért a böngészők, gyorsítótárak és közbenső komponensek előre betölthetik vagy újrakérhetik. Üzleti módosítást ezért nem szabad GET-tel kifejezni.
„REST” és „REST-szemléletű HTTP API”
A gyakorlatban sok „REST API” főnévi útvonalakkal és JSON-nal dolgozik, de kevés hipermédiát használ. Ezért pontosabb REST-szemléletű HTTP API-ról beszélni, és megnevezni, mely korlátokat valósítja meg. Az útvonal alakja önmagában nem teljesíti az architekturális korlátokat. A stateless azt jelenti, hogy a kérés feldolgozásához szükséges klienskontextus nem rejtett korábbi beszélgetésből származik; a szervernek lehet tartós üzleti állapota (például egy foglalás), az adatbázis használata nem sérti a korlátot.
Jellemzők
Szempont
REST-szemléletű HTTP API
Irány
Kétirányú üzenetváltás, de kérésenként; a szerver magától nem küld
Kezdeményező
Mindig a kliens
Kapcsolat tartóssága
Kérésenként új vagy újrahasznosított kapcsolat; a protokoll állapotmentes
Késleltetés
Egy kérés–válasz út; a változás észlelése a következő kérésig késik
Terhelés
A kérések számával arányos; a gyorsítótár csökkentheti
Hibatűrés
Egyszerű: a hibás kérés ismételhető, ha idempotens (6.5)
Mikor jó?
Erőforrás-szemléletű, jól gyorsítótárazható, sok fogyasztós szolgáltatások
Mikor nem?
Sokféle összetett lekérdezés, sok hívást igénylő aggregáció, a szerver felől érkező változás
Miért hasznos ez szolgáltatások között?
A HTTP széles körben támogatott, a kérés és a válasz jól megfigyelhető, a protokoll státuszokat, gyorsítótár- és feltételes kérési eszközöket ad. Cserébe az erőforrás-modell nem minden művelethez természetes, és több összefüggő adat lekérdezése sok hívást okozhat (6.3).
Gyakori tévhitek
Állítás
Pontosítás
„A REST = JSON HTTP fölött.”
A REST korlátok halmaza; a JSON és a HTTP csak egy megvalósítás.
„A stateless API-nak nincs adatbázisa.”
A kérésenkénti kontextus nem rejtett; az üzleti állapot tartós lehet.
„A főnévi útvonal REST-tté teszi az API-t.”
Az útvonal alakja nem teljesíti a korlátokat.
„A DELETE ismétlése hibát jelent.”
Idempotens: a hatás ugyanaz, a válasz eltérhet.
Röviden
A REST architekturális korlátok halmaza: kliens–szerver, stateless, gyorsítótárazhatóság, egységes interfész, rétegezett rendszer.
A kliens reprezentációt kap, nem belső objektumot.
A gyakorlatban gyakori a REST-szemléletű HTTP API, kevés hipermédiával.
A kezdeményező mindig a kliens; a szerver felől érkező változáshoz más módszer kell.
Ellenőrző kérdések
Melyek a REST korlátai, és melyik opcionális?
Miért nem ellentmondás a stateless API és a tartós üzleti állapot?
REST: erőforrás, reprezentáció és egységes interfész
Célok
A lecke végére el tudod magyarázni a REST architekturális korlátait, meg tudod különböztetni a REST-szemléletű HTTP API-t a „JSON HTTP fölött” megoldástól, és a hét szempont szerint jellemezni tudod.
Miért kell?
Szolgáltatások között a hívás jelentését és a közös szabályokat meg kell állapítani. A REST nem egy konkrét API-formátum, hanem egy architekturális stílus, amelynek célja, hogy a komponensek egységes, jól megfigyelhető és gyorsítótárazható módon kommunikáljanak. Roy Fielding doktori értekezése írta le.
Mi a REST?
A REST Fielding szerint korlátok halmaza:
Az erőforrás bármi, amit azonosítani lehet (egy rendelés, egy gyűjtemény). A kliens az erőforrás reprezentációját kapja, nem a belső objektumot vagy adatbázissort. Ugyanaz az erőforrás több formátumban is megjelenhet; a
Content-Typeés az elfogadott formátumokról szóló megállapodás teszi értelmezhetővé.Metódusok és szándék
Az RFC 9110 alapján a
GETolvasási szándékú, biztonságos és idempotens; aPUTés aDELETEidempotens; aPOSTaz erőforráshoz kötődő feldolgozást kér, nem idempotens. A biztonságos metódus ismétlése vagy előzetes betöltése nem kell hogy üzleti változást okozzon, ezért a böngészők, gyorsítótárak és közbenső komponensek előre betölthetik vagy újrakérhetik. Üzleti módosítást ezért nem szabadGET-tel kifejezni.„REST” és „REST-szemléletű HTTP API”
A gyakorlatban sok „REST API” főnévi útvonalakkal és JSON-nal dolgozik, de kevés hipermédiát használ. Ezért pontosabb REST-szemléletű HTTP API-ról beszélni, és megnevezni, mely korlátokat valósítja meg. Az útvonal alakja önmagában nem teljesíti az architekturális korlátokat. A stateless azt jelenti, hogy a kérés feldolgozásához szükséges klienskontextus nem rejtett korábbi beszélgetésből származik; a szervernek lehet tartós üzleti állapota (például egy foglalás), az adatbázis használata nem sérti a korlátot.
Jellemzők
Miért hasznos ez szolgáltatások között?
A HTTP széles körben támogatott, a kérés és a válasz jól megfigyelhető, a protokoll státuszokat, gyorsítótár- és feltételes kérési eszközöket ad. Cserébe az erőforrás-modell nem minden művelethez természetes, és több összefüggő adat lekérdezése sok hívást okozhat (6.3).
Gyakori tévhitek
Röviden
Ellenőrző kérdések
GET-tel vásárlást kifejezni?Források