a REST a Reprezentációs állami transzfert jelenti, amelyet Roy Fielding 2000-ben hozott létre. Ez egy építészeti stílus a lazán összekapcsolt alkalmazások HTTP-n keresztüli tervezéséhez, amelyet gyakran használnak a webszolgáltatások fejlesztésében. A REST nem hajt végre semmilyen szabályt arra vonatkozóan, hogy hogyan kell alacsonyabb szinten végrehajtani, csak magas szintű tervezési irányelveket fogalmaz meg, és hagyja, hogy gondolkodjon a saját megvalósításán.
az utolsó munkahelyemen RESTful API-kat terveztem egy nagy távközlési vállalat számára két jó évig. Ebben a bejegyzésben, megosztom gondolataimat a szokásos tervezési gyakorlatokon kívül. Lehet, hogy nem ért egyet velem néhány kérdésben, és ez teljesen rendben van. Örömmel fogok beszélni bármiről, amit Ön nyitott elmével mond.
kezdjük a szabványos tervezéssel, hogy tisztázzuk, mit akar ‘Roy Fielding’ építeni. Ezután megbeszéljük a gondolataimat, amelyek inkább finomabb pontok felé mutatnak, miközben megtervezi a nyugodt API-kat.
építészeti korlátok
a REST 6 építészeti kényszert határoz meg, amelyek bármely webszolgáltatást valódi RESTful API – vá tesznek.
- egységes interfész
- kliens-szerver
- hontalan
- gyorsítótárazható
- réteges rendszer
- Kód igény szerint (opcionális)
egységes felület
mivel maga a kényszer neve is érvényes, el kell döntenie a rendszeren belüli erőforrások API-interfészét, amelyek API-fogyasztóknak vannak kitéve, és vallásosan követik őket. A rendszerben lévő erőforrásnak csak egy logikai URI-val kell rendelkeznie, amely lehetővé teszi a kapcsolódó vagy további adatok lekérését. Mindig jobb, ha egy erőforrást egy weboldallal szinonimizálunk.
egyetlen erőforrás nem lehet túl nagy, és tartalmazhat mindent a reprezentációjában. Amikor releváns, az erőforrásnak tartalmaznia kell a relatív Uri-kra mutató hivatkozásokat (HATEOAS) a kapcsolódó információk lekéréséhez.
ezenkívül a rendszeren belüli erőforrás-ábrázolásoknak konkrét irányelveket kell követniük, például elnevezési konvenciókat, linkformátumokat vagy adatformátumokat (XML vagy/és JSON).
minden erőforrásnak elérhetőnek kell lennie egy közös megközelítésen keresztül, mint például a HTTP GET, és hasonlóan módosítani kell egy következetes megközelítés használatával.
Client–server
ez a korlátozás lényegében azt jelenti, hogy az ügyfélalkalmazásnak és a szerveralkalmazásnak képesnek kell lennie arra, hogy egymástól függetlenül fejlődjön. Az ügyfélnek csak erőforrás-URI-kat kell ismernie, és ez minden. Ma ez a szokásos gyakorlat a webfejlesztésben, így semmi Divatos Nem szükséges az Ön oldalán. Legyen egyszerű.
hontalan
Roy fielding kapott ihletet HTTP, így tükrözi ezt a korlátozást. Az összes kliens-szerver interakció hontalanná tétele. A szerver nem tárol semmit az ügyfél által készített legújabb HTTP-kérésről. Minden kérést újként fog kezelni. Nincs ülés, nincs történelem.
ha az ügyfélalkalmazásnak stateful alkalmazásnak kell lennie a végfelhasználó számára, ahol a felhasználó egyszer bejelentkezik, és ezt követően más engedélyezett műveleteket hajt végre, akkor az ügyfél minden kérésének tartalmaznia kell a kérés kiszolgálásához szükséges összes információt-beleértve a hitelesítési és engedélyezési adatokat is.
gyorsítótárazható
a mai világban az adatok és válaszok gyorsítótárazása rendkívül fontos, bárhol is alkalmazható/lehetséges. Az itt olvasott weboldal a HTML oldal gyorsítótárazott változata is. A gyorsítótárazás javítja az ügyféloldali teljesítményt, és nagyobb teret biztosít a kiszolgálók skálázhatóságának, mivel a terhelés csökkent.
REST esetén a gyorsítótárazást az erőforrásokra kell alkalmazni, majd ezeknek az erőforrásoknak gyorsítótárazhatónak kell nyilvánítaniuk magukat. A gyorsítótár a szerveren vagy a kliens oldalon valósítható meg.
réteges rendszer
a REST lehetővé teszi egy réteges rendszerarchitektúra használatát, ahol az API-kat az A kiszolgálón telepíti, az adatokat pedig a B kiszolgálón tárolja, és például a C kiszolgálón hitelesíti a kéréseket. Az ügyfél általában nem tudja megmondani, hogy közvetlenül csatlakozik-e a végkiszolgálóhoz vagy egy közvetítőhöz.
igény szerinti Kód (opcionális)
Nos, ez a korlátozás nem kötelező. Legtöbbször az erőforrások statikus ábrázolását XML vagy JSON formájában küldi el. De ha kell, akkor szabadon return executable code, hogy támogassa egy részét az alkalmazás, például az ügyfelek hívja az API, hogy egy UI widget rendering kódot. Ez megengedett.
vegye figyelembe, hogy a fenti korlátozások a legszorosabban kapcsolódnak a WWW-hez (a webhez). A RESTful API-k használatával ugyanazt teheti a webszolgáltatásaival, mint a weboldalakkal.