REST protokoll tervezése
Az XML.com a napokban indította el a The Restful Web című rovatát, mely a REST architektúra szerint tervezett alkalmazások problémáit fogja körüljárni. Avatócikkében Joe Gregorio nagyon praktikusan próbálja megfogni az alapkérdést, mégpedig hogy mik egy REST architektúra szerint kialakított protokoll építőelemei. Azok számára, akiknek a REST nem ismerős, annyit mindenképpen érdemes tudni, hogy ez a módszer a web alapelemeit veszi újra elő, és ahelyett, hogy mondjuk a HTTP feletti XML szinten oldaná meg az adattovábbítás és tárgyazonosítás probelémáit, a lehető legtöbb feladatot meglévő eszközökkel - HTTP metódusokkal és URI-kkel old meg.
Miről is van szó konkréten? Képzeljük el, hogy egy asztali blog szerkesztő alkalmazást kell írnunk. Ennek legalább képesnek kell lennie új bejegyzések felvitelére, meglévők szerkesztésére, törlésére. Ha mindezt mondjuk a célra jelenleg legnépszerűbb Blogger API segítségével oldjuk meg, akkor a HTTP kommunikáció feletti XML-RPC-t alkalmazzuk, amiben az említett funkcióknak megfelelő eljárásokat hívunk meg, és paramétereket adunk át, majd egy XML-RPC válaszban érkezik a visszajelzés - esetleges hibaüzenet. Ha ugyanezt REST szemlélettel oldjuk meg, akkor felismerjük, hogy a HTTP biztosít GET, POST, PUT, DELETE metódusokat, melyek pontosan a kívánt funkcióknak felelnek meg. Azt, hogy mivel végezzük a műveletet, szükségtelen egy XML struktúrában elrejteni, hiszen az URI alapvető célja az erőforrások megnevezése. Új beküldésnél megadhatjuk a webhelyünk gyökércímét, egy konkrét bejegyzés szerkesztésénél az adott oldal címét. A hibakezelés is a HTTP hibakódjai segítségével történik, ezek ugyanis eléggé széles skálán definiáltak, csak a hétköznapokon nem sokat használunk belőlük. Az Atom éppen ezt a megközelítést képviseli.
Nade nem minden a bejegyzések beküldéséről és szerkesztéséről szól, és itt kapcsolódik be az XML.com cikke, melyben saját REST alapú protokollunk tervezéséhez kaphatunk segítséget. A feltett kérdések sorban: milyen URI-ket használunk, milyen formátumban szállítjuk az adatokat, milyen metódusokat támogatunk az egyes címeken, illetve milyen válaszkódokat fogunk alkalmazni. Mindez persze messze nem a teljes feladat, a sorozat további részeiben többek között a tömörítés, gyorsítótárazás, kiterjeszthetőség kérdését is górcső alá fogja venni a szerző.
■ Miről is van szó konkréten? Képzeljük el, hogy egy asztali blog szerkesztő alkalmazást kell írnunk. Ennek legalább képesnek kell lennie új bejegyzések felvitelére, meglévők szerkesztésére, törlésére. Ha mindezt mondjuk a célra jelenleg legnépszerűbb Blogger API segítségével oldjuk meg, akkor a HTTP kommunikáció feletti XML-RPC-t alkalmazzuk, amiben az említett funkcióknak megfelelő eljárásokat hívunk meg, és paramétereket adunk át, majd egy XML-RPC válaszban érkezik a visszajelzés - esetleges hibaüzenet. Ha ugyanezt REST szemlélettel oldjuk meg, akkor felismerjük, hogy a HTTP biztosít GET, POST, PUT, DELETE metódusokat, melyek pontosan a kívánt funkcióknak felelnek meg. Azt, hogy mivel végezzük a műveletet, szükségtelen egy XML struktúrában elrejteni, hiszen az URI alapvető célja az erőforrások megnevezése. Új beküldésnél megadhatjuk a webhelyünk gyökércímét, egy konkrét bejegyzés szerkesztésénél az adott oldal címét. A hibakezelés is a HTTP hibakódjai segítségével történik, ezek ugyanis eléggé széles skálán definiáltak, csak a hétköznapokon nem sokat használunk belőlük. Az Atom éppen ezt a megközelítést képviseli.
Nade nem minden a bejegyzések beküldéséről és szerkesztéséről szól, és itt kapcsolódik be az XML.com cikke, melyben saját REST alapú protokollunk tervezéséhez kaphatunk segítséget. A feltett kérdések sorban: milyen URI-ket használunk, milyen formátumban szállítjuk az adatokat, milyen metódusokat támogatunk az egyes címeken, illetve milyen válaszkódokat fogunk alkalmazni. Mindez persze messze nem a teljes feladat, a sorozat további részeiben többek között a tömörítés, gyorsítótárazás, kiterjeszthetőség kérdését is górcső alá fogja venni a szerző.
