REST alapú kommunikáció

Mi a REST?

A REST egy HTTP protokollra fejlesztett kommunikációs architektúra típus, mely kliens és szerver közti kommunikáció megvalósítására használható. Kihasználja a HTTP állapotkódokat és metódusokat egyaránt, sőt a specifikáció megköveteli azok használatát, bár az egyedi fejlesztésű REST interfészek tervezése során ezekre gyakran nem ügyelnek a fejlesztők. A kérések URI-k használatával történnek, melyek erőforrásokat azonosítanak, és az URI-k egységes interfészt biztosítanak a kliens számára. Minden kérésre azonos formátumban reagál a szerver, ez általában JSON, de használható még HTML és XML formátum is. Fontos, hogy a kérések állapotmentesek, tehát nem beszélhetünk „munkafolyamatról”, így az authorizáció folyamatos figyelmet igényel.

Jogosultság ellenőrzés

Megeshet, hogy egy publikus REST interfész fejlesztése a feladat, de általában ez így nem lesz, biztosítani kell az erőforrások védelmét a jogosulatlan hozzáférésekkel szemben - főleg, ha „írási” műveleteket is lehetővé tesz az interfész. Mivel állapotmentes technológiáról beszélünk, nem tehetjük meg azt, hogy a kliens küld egy „bejelentkezési kérelmet” a szervernek; majd a szerver elindítja a munkafolyamatot és innentől kényelmesen történik a kommunikáció. Ez esetben ez sajnos nem fog működni.

Nyilván így minden kérésben azonosítani kell a klienst, hogy a szerver tudja, milyen jogok vannak számára kiosztva, mely erőforrásokat elérését biztosíthatja. A legfapadosabb megoldás, hogy az URI-ban GET vagy a kérés fejlécében POST paraméterekként megadjuk a kliens azonosítására szolgáló adatokat (felhasználónév – jelszó párost, vagy tokent). Ez azonban csak akkor fog működni, ha a szerver GET vagy POST kérésre reagál, és így ráadásul minden kérésnél ügyelni kell, hogy az azonosító a megfelelő helyen szerepeljen a kérésben. Így azonban sérül az egységesség, gyakorlatilag ez az esetek közel 100%-ában nem járható út.

Az azonosítást éppen ezért a kérés fejlécében, az Authorization mezőben szokás elvégezni. Itt több lehetőségünk is lesz, a legkézenfekvőbb megoldás a Basic mód használata. Paraméterül egy Base64-be kódolt string-et vár, mely a felhasználónevet és a jelszót tartalmazza kettősponttal összefűzve. A példa kedvéért legyen a felhasználónév „rest”, a jelszó pedig „R3st”, tehát a „rest:R3st” string-et kell Base64-be kódolni. A HTTP header ekkor a következőt kell tartalmazza:

Authorization: Basic cmVzdDpSM3N0

A szerver ezt automatikusan fel tudja dolgozni, és PHP-s környezetben például a $_SERVER szuperglobális tömb PHP_AUTH_USER és PHP_AUTH_PW mezőibe fogja írni. Nyilván ez a megoldás nem a legbiztonságosabb ilyen formában, így érdemes megfontolni más módszer használatát, vagy legalább a felhasználónevet és/vagy a jelszót egyféle tokenizálásnak is alávetni.

De ha már token, lehetőségünk van közvetlenül egy tokent is átadni az Authorization mezőben. Ehhez Basic helyett Bearer módszer használatára lesz szükség, bár ez megköveteli a szerverkörnyezeten az OAuth modul létezését – erről bővebb információk az OAuth dokumentációjában olvashatóak.

Állapotkódok

A kliens alkalmazásban a kérésre kapott választ a legegyszerűbben úgy dolgozható fel, ha a szerver a választ a megfelelő állapotkóddal látja el. Szabadon használható bármely standard HTTP státuszkód, néhány példa:

• a sikeres teljesítésről 200-as kóddal tájékoztathatjuk a klienst;
• a sikertelen authorizációt 401-gyel jelezhetjük;
• amennyiben az alkalmazás nem létező erőforrást próbált elérni, a 404-es hibakód a hibátlan megoldás;
• egyes esetekben bizonyos erőforrás kérések csak megfelelő metódusokkal érhetőek el. Helytelen metódus használatáról a 405-ös kód tájékoztat;

és így tovább. Ne sajnáljuk ezeket használni!

Metódusok

A REST erőforrások a specifikációnak megfelelően nem csak információkat képesek szolgáltatni, hanem adatok, erőforrások szerveren való elhelyezését is lehetővé teszik. Egy erőforrás létrehozása általában már eleve nem lehetséges GET metódus használatával, így a REST lehetőséget biztosít bármely standard HTTP metódus használatára. Ha a hívott erőforrásnál be van állítva, mely metódusokra reagáljon, csak azokra fog, minden ellenkező irányú próbálkozás hibaüzenetet, kivételt fog generálni.

Az általános irányelvek szerint

• erőforrás kérése GET metódussal történik;
• egyszerű adatok szerverre küldését POST metódussal végezhetjük;
• erőforrás elhelyezését a PUT metódus teszi lehetővé;
• létező erőforrás frissítése a PATCH metódussal lehetséges;
• erőforrás eltávolítását pedig DELETE-tel végezhetjük.

Sajnos sikerült már olyan REST interfésszel találkoznom, ahol valahogy egyáltalán nem foglalkoztatta a fejlesztőket sem az állapotkódok, sem a metódusok használata – mindenre 200-as kóddal reagált a rendszer és minden kérés GET metódussal történt. Természetesen ez is működő megoldás, hiszen a REST interfészen kommunikáló rendszerek úgyis egymáshoz vannak igazítva általában, azonban a legtöbb keretrendszer számít a specifikációban foglaltak alkalmazására. Remek megoldás, ha egy hibás kérésre 200-as állapotkódú válaszban egy hibakódot és annak leírását küldi a szerver, épp csak lehet, hogy meg fogja fektetni a kliens által használt feldolgozót, óriási kivételt, és a fejlesztőknek néhány óra hajtépést eredményezve.

A tervezés és fejlesztés során tehát fontos nagy figyelmet fektetni a specifikáció követésére mind szerver, mind kliens oldalon. A biztosított interfész egységes kell, legyen, és mivel a válaszok önleíróak, a kliens számára egyértelműen eldönthetőnek kell lenni a feldolgozás mikéntjének.

Komment írásához jelentkezz be
Bejelentkezés