Szia! Ma egy nagyon érdekes, és ami a legfontosabb, a munkaerőpiacon nagyon keresett témával ismerkedünk meg: REST. A REST áttekintését három részre osztjuk:
Az első részben a REST történetével foglalkozunk, és ismertetjük azokat az elveket, amelyeken a REST alapul.
A másodikban megvizsgáljuk, hogyan megy végbe a kommunikáció a kliens és a szerver között a HTTP protokollon keresztül.
A harmadikban egy kis RESTful alkalmazást írunk, amit a "Postman" nevű programmal tesztelünk.
A cikk azoknak az olvasóknak szól, akik ismerik a következő kifejezéseket:
HTTP
URL és URI
JSON és (kisebb mértékben) XML
Függőség injekció
1. rész Mi a REST?
A REST, mint az IT-világban oly sok, egy mozaikszó. A "REpresentational State Transfer" szóból származik . Ez egy architekturális stílus az elosztott rendszer összetevői közötti interakcióhoz egy számítógépes hálózatban. Egyszerűen fogalmazva, a REST meghatározza a rendszer különböző összetevői közötti interakció (adatcsere) stílusát, amelyek mindegyike fizikailag különböző helyeken helyezkedhet el. Ez az építészeti stílus az elosztott rendszer tervezésekor betartott megszorítások következetes halmaza. Ezeket a megszorításokat néha a REST vezérelveinek is nevezik. Nem sok van, csak 6. Róluk egy kicsit később lesz szó.
Azokat az alkalmazásokat, amelyek a REST elvek figyelembevételével készültek, azaz azokat, amelyek nem sértik a REST megkötéseket, "RESTful"-nak nevezik.
A REST története
A REST kifejezést Roy Fielding, a HTTP protokoll egyik megalkotója vezette be Ph.D-jében. Az "Architectural Styles and the Design of Network-based Software Architectures" címet viselő szakdolgozat 2000-ben készült. Bár a REST kifejezést még fiatalnak nevezhetjük, az általa képviselt koncepció a World Wide Web magja. Nem merülünk el mélyen a kifejezés történetében. Ha az elsődleges forrásokba szeretne belemerülni, vessen egy pillantást Fielding disszertációjára .
A REST korlátai és alapelvei
Ahogy fentebb említettük, a REST meghatározza, hogy az elosztott rendszer összetevői hogyan működjenek együtt egymással. Ez általában egy kérés-válasz folyamaton keresztül történik. A kérést küldő összetevőt kliensnek , a kérést feldolgozó és a kliensnek választ küldő komponenst pedig szervernek nevezzük .. A kéréseket és válaszokat leggyakrabban HTTP protokollon keresztül küldik. A HTTP a HyperText Transfer Protocol rövidítése. A szerver általában valamilyen webes alkalmazás. Az ügyfél szinte bármi lehet. Például egy mobilalkalmazás, amely adatokat kér egy szervertől. Vagy egy böngésző, amely kéréseket küld egy weboldalról a szerverre adatok letöltése érdekében. Az A alkalmazás adatokat kérhet a B alkalmazástól. Ebben az esetben A kliens B vonatkozásában, B pedig kiszolgáló A számára. Ugyanakkor A feldolgozhatja a B, C, D stb. kéréseit. Ebben az esetben az A alkalmazás kiszolgáló és kliens is egyben. Minden a kontextustól függ. Egy dolog biztos: a kérést küldő komponens az ügyfél. A kérést fogadó, feldolgozó és azokra válaszoló összetevő a szerver. Azonban, nem minden rendszer, amelynek összetevői kérés-válasz folyamaton keresztül kommunikálnak, RESTful rendszer. Ahhoz, hogy egy rendszer RESTfulnak minősüljön, meg kell felelnie a hat REST megkötésnek:
1. Kliens-szerver architektúra
Ez a megkötés az aggodalmak szétválasztására vonatkozik. El kell választani a kliens felület követelményeit az adatokat tároló szerver követelményeitől. Ez a megszorítás a kliens kódot hordozhatóbbá teszi más platformokra, a szerveroldal egyszerűsítése pedig javítja a rendszer méretezhetőségét. A „kliens” és a „szerver” közötti különbségtétel lehetővé teszi, hogy egymástól függetlenül fejlesszük őket.
2. Hontalan
A RESTful architektúrához a következő feltételeknek kell teljesülniük. A kérések közötti időszakban a szerver nem tárolhat információt a kliens állapotáról és fordítva. Az ügyféltől érkező összes kérést úgy kell összeállítani, hogy a szerver minden szükséges információt megadjon a kérés teljesítéséhez. Így a szerver és a kliens is „megért” minden kapott üzenetet anélkül, hogy a korábbi üzenetekre hagyatkozna.
3. Gyorsítótárazható
Az ügyfelek gyorsítótárazhatják a szerver válaszait. Ezeket pedig kifejezetten vagy implicit módon gyorsítótárazottként vagy nem gyorsítótárazottként kell megjelölni, hogy az ügyfelek ne kapjanak elavult vagy helytelen adatokat a későbbi kérésekre válaszul. A helyes gyorsítótárazás segít részben vagy teljesen kiküszöbölni egyes kliens-szerver interakciókat, tovább növelve a rendszer teljesítményét és méretezhetőségét.
4. Egységes felület
A RESTful architektúra alapvető követelményei közé tartozik az egységes, egységes felület. A kliensnek mindig meg kell értenie, hogy milyen formátumot és címeket kell használnia a kérés elküldésekor, a szervernek pedig azt is meg kell értenie, hogy milyen formátumot kell használnia a kliens kérések megválaszolásakor. Ez a konzisztens kliens-szerver interakció, amely leírja, hogy mit, hová, milyen formában és hogyan kell küldeni, egy egységes felület.
5. Rétegek
A rétegek alatt a hálózat hierarchikus felépítését értjük. Néha egy kliens közvetlenül kommunikálhat a szerverrel, néha pedig csak egy köztes csomóponttal kommunikál. A köztes szerverek használata növelheti a méretezhetőséget a terheléselosztásnak és az elosztott gyorsítótárnak köszönhetően. Mondjunk egy példát. Képzeljen el egy mobilalkalmazást, amely az egész világon népszerű. Az alkalmazás szerves része a képek betöltése. Felhasználóinak száma milliós nagyságrendű, így egyetlen szerver sem tud ilyen nagy terhelést elviselni. A rendszer rétegekre bontása megoldja ezt a problémát. Ha a kliens képet kér egy köztes csomóponttól, akkor a közbenső csomópont az éppen legkevésbé terhelt szervertől kéri le a képet, és visszaküldi a képet a kliensnek. Ha a gyorsítótárazást helyesen alkalmazzák a hierarchia minden szintjén,
6. Igény szerinti kód (nem kötelező)
Ez a megszorítás azt jelenti, hogy a kliens kisalkalmazások vagy szkriptek formájában kódot tölt le a kiszolgálóról a funkcionalitás bővítésére.
A RESTful architektúra előnyei
Azok az alkalmazások, amelyek megfelelnek az összes fent említett megkötésnek, a következő előnyökkel rendelkeznek: megbízhatóság (nem kell menteni az ügyfél állapotát, ami elveszhet)
teljesítmény (a gyorsítótár használata miatt)
méretezhetőség
átlátható kommunikáció
egyszerű felületek
hordozhatóság
könnyű változtatási képesség
képesség a fejlődésre és az új követelményekhez való alkalmazkodásra
A REST áttekintését három részre osztjuk:
