Gondolatok a REST-ről 10 pontban, I. rész

Továbbra is igaz, hogy ha valamit megtudunk a REST-ről, végül azon kezdünk el gondolkodni, hogy a fogalom mennyire alkalmazható a mi saját, adott forgatókönyvünk esetén. Maga a REST a Representational State Transfer rövidítése, mely egy olyan architektúra, ami meghatározza, hogy a webes erőforrásokat hogyan definiáljuk és címezzük.Mivel valószínűleg teljesen más architekturális megközelítéshez vagyunk hozzászokva, természetes, ha kétségbe vonjuk, hogy a REST vagy inkább a RESTesített HTTP a gyakorlatban is működik, vagy úgy gondoljuk, hogy egyszerűen nem működik, ha komolyabb dolgokra szeretnénk használni. Ebben a cikkben a REST-tel kapcsolatban előforduló tíz leggyakoribb kétséget taglaljuk, melyek főleg akkor jelentkeznek, amikor az emberek elkezdik felfedezni, és különösen akkor, ha a SOAP/WSDL alapú webszolgáltatásokkal kapcsolatban már rendelkeznek szilárd architekturális háttérrel.

1. A REST talán alkalmazható CRUD-hoz, de nem alkalmazható a „valós” üzleti logikához

Ez a leggyakoribb reakció, melyet a REST előnyeivel kapcsolatos szkepticizmus megnyilvánulásaként tapasztalhatunk. Végül is, ha csak CRUD műveleteket (Create – létrehozás, Read – olvasás, Update – frissítés, Delete –törlés) hajtunk végre, akkor hogyan lehetséges, hogy összetettebb alkalmazási szemantikát fejezzünk ki?

Először is, a HTTP műveletek – Get, Put, Post és Delete – nem képezhetők le egy az egyben a CRUD adatbázis műveletekhez. Például mind a Post mind a Put művelet felhasználható új erőforrások létrehozása során, azonban különböznek abban, hogy a Put esetén a kliens az, aki meghatározza az erőforrás URI-ját (amit majd frissítenek vagy létrehoznak), míg a Post egy „collection” vagy „factory” erőforráshoz kapcsolódik, és a szervernek a feladata, hogy az URI-t hozzárendelje. Térjünk azonban vissza a kérdésre, hogy hogyan kezelünk összetettebb üzleti logikát?

Bármilyen művelet (calc (a, b)), mely egy adott c eredménnyel tér vissza, átalakítható egy olyan URI-vá, mely a számítás eredményét azonosítja. Például az x= calc (2,3) az alábbi URI-t eredményezi: http://example.com/calculation?a=2&b=3. Először ez úgy tűnik, mintha csúnyán visszaélnénk a RESTesített HTTP-vel; az URI-kat nem erőforrások azonosításához kellene használni a műveletek azonosítása helyett? Igen, de lényegében ezt is tesszük: a http://example.com/sum?augend=2&addend=3 egy erőforrást azonosít, mégpedig a 2 és 3 összeadásának eredményét. Ha ebben az adott (nyilvánvalóan jól kigondolt) példában a Get műveletet arra használjuk, hogy az eredményt visszakapjuk, ez egy jó ötlet; végül is gyorstárazható (cache), hivatkozhatunk rá, és a számítás valószínűleg biztonságos és nem nagyon költséges.

Természetesen sok esetben rossz megközelítésnek bizonyulhat, ha a Get műveletet valaminek a kiszámítására használjuk. Emlékezzünk rá, hogy a Get „biztonságos” művelet kell, hogy legyen, azaz a kliens nem fogad el semmi kötelezettséget (például, hogy fizessen a szolgáltatásunkért), vagy nem feltételez semmilyen felelősséget, amikor csak a hivatkozást követi, a Get parancson keresztül. Sok más esetben ezért ésszerű, ha beviteli adatot nyújtunk a szervernek, így az új erőforrásokat tud létrehozni a Post műveleten keresztül. A szerver a válaszában jelezni tudja az eredmény URI-ját (és lehetőleg egy átirányítást eszközölhet, hogy odavigyen). Ennek az eredménye aztán újból használható, könyvjelzők közé hozzáadható, és a megjelenítés után gyorstárazható. Alapjában véve ezt a modellt bármilyen olyan műveletre kiterjeszthetjük, melynek van eredménye, tehát gyakorlatilag mindegyikre.

2. Nincs formális kontraktus és leíró nyelv

Az RPC-től a CORBA-ig, a DCOM-tól a webszolgáltatásokig, hozzá vagyunk ahhoz szokva, hogy van egy interfész leírás, ami a műveleteket, azok nevét, illetve a beviteli és kiviteli paramétereiket listázza. Hogyan használhatjuk a REST-et az interfész leíró nyelv nélkül? Erre a gyakran feltett kérdésre három válasz van.

Először is, ha amellett döntünk, hogy RESTesített HTTP-t használunk XML-lel együtt, ami egy nagyon gyakori választás, még mindig elérhetők számunkra az XML séma nyelvek, csakúgy, mint a DTD-k, az XML Schema, a RELAX NG vagy a Schematron. A WSDL használatával létrehozott leírások 95 százaléka egyáltalán nincs WSDL-hez kötve, hanem inkább azokhoz az XML Schema-ban lévő összetett típusokhoz kapcsolódik, melyeket meghatározunk. Amit a WSDL ehhez hozzáad, az leginkább a műveletek és azok nevei; ezek leírása meglehetősen unalmassá válik a REST egységes interfészével. Végül is a Get, Put, Post és Delete az összes lehetséges művelet. Az XML Schema használatát illetően ez azt jelenti, hogy a kedvenc adat kapcsolati eszközünket (már ha van ilyan) használhatjuk az adat kapcsolati kód generálásához a választott nyelvhez, még akkor is, ha RESTesített interfészre támaszkodunk. (ez nem a teljes válasz, lásd később)

Másodszor, fontos, hogy megkérdezzük magunktól, hogy miért is van szükségünk a leírásra. A leggyakoribb, habár nem az egyetlen felhasználási eset, hogy a leírandó interfész stubjainak és skeletonjainak generálásához használjuk a leírást. Ez általában nem a dokumentáció, mivel a leírás (például WSDL formátumban) nem mond semmit a műveletek szemantikájáról, csak egy nevet tartalmaz. Szükség van valami olvasható dokumentációra, hogy tudjuk hogy kell meghívni a műveletet. Egy tipikus REST megközelítés esetén HTML formátumú dokumentációt nyújtunk, lehetőleg közvetlen hivatkozásokkal az erőforrásokhoz. Ha azt a megközelítést alkalmazzuk, hogy több reprezentációt használunk, talán önmagukat dokumentáló erőforrásaink is lehetnek, csak ki kell egy HTTP Get parancsot adnunk egy erőforráson a böngészőnkben, és egy HTML dokumentumot kapunk, ami adatokat, valamint a rajta elvégezhető műveletek listáját is tartalmazza (HTTP műveletek), illetve a tartalom típusokat, melyeket elfogad és nyújt.

Végül, ha ragaszkodunk a leíró nyelv használatához a RESTesített szolgáltatásaink esetén, akkor webes alkalmazás leíró nyelvet (WADL) használhatunk, vagy bizonyos korlátokkal WSDL 2.0-át, ami a szerzői szerint képes a RESTesített szolgáltatások leírására is. Sem a WADL sem a WSDL 2 nem használhatók hatékonyan hipermedia leírására, noha a REST-nek ez az egyik alapvető tulajdonsága.