3. Ki tárná a nyilvánosság elé az alkalmazásának implementációs részleteit?
Egy másik gyakori aggodalom, hogy az erőforrások túl alacsony szintűek, azaz az implementáció részleteit nem célszerű nyilvánossá tenni. Végül is ez az erőforrások használatának a terhét rója majd ránk azért, hogy valami értelmeset érjünk el a klienssel?
A rövid válasz: nem. A get, a put vagy bármilyen más módszer egy erőforráson olyan egyszerű vagy olyan összetett lehet, mint egy „szolgáltatás” vagy egy RPC művelet implementációja. A REST tervezési elveinek alkalmazása nem jelenti azt, hogy az alapot képező adatmodell egyedi elemeinek részleteit nyilvánosságra kell hoznunk, csak azt jelenti, hogy ahelyett, hogy az üzleti logikát működés-centrikus módon hozzuk nyilvánosságra, ezt adat-centrikus módon tesszük.
Egy ehhez kapcsolódó aggodalom, hogy ha az erőforrásokhoz nem nyújtunk közvetlen hozzáférést, ez a biztonságot növeli. Ez azon a régi téveszmén alapul, hogy az átláthatatlanság biztonságot eredményez, de az igazság pont ennek az ellentettje. Azáltal, hogy elrejtjük, hogy milyen egyedi erőforrásokhoz férünk hozzá az alkalmazás specifikus protokollunkban, az infrastruktúrát már nem tudjuk könnyen alkalmazni arra, hogy megvédjük ezeket az erőforrásokat. Ha az értelmes erőforrásokhoz egyedi URI-kat rendelünk hozzá, ehhez használhatunk például Apache biztonsági szabályokat (valamint átíró logikát, naplózást, statiszikát stb.), hogy a különböző erőforrások esetén különbözőféleképpen működjenek. Ezek nyilvánossá tételével nem csökkentjük, hanem növeljük a biztonságot.
4. A REST csak HTTP-vel működik, és nem független a transzport protokolltól
Először is kihangsúlyozandó, hogy a HTTP nem egy transzport protokoll, hanem egy alkalmazási protokoll, mely TCP-t használja az alapot képező protokollként, de a szemantikája ezen túlmutat (ha nem így lenne, akkor nem sok haszna lenne). Ha a HTTP-t csupán transzporta használjuk, akkor viszaélünk vele.
Másodszor, az absztrakció nem mindig jó ötlet. A webszolgáltatások azt a megközelítést követik, hogy megpróbálnak sok különböző technológiát egyetlen absztrakciós réteg mögé rejteni, de az absztrakciókra jellemző, hogy hézagosak. Például hatalmas különbség van aközött, hogy egy üzenetet JMS-en keresztül vagy HTTP kérésként küldünk. Az, hogy a teljesen különböző opciókat lebutítjuk a legnagyobb közös nevezőjükre, senkinek sem jó. Vegyünk egy példát: megtehetnénk, hogy létrehozunk egy olyan általános absztrakciót, amely a relációs adatbázist és a fájlrendszert egy közös API alá rejti. Természetesen ez megtehető, de amint olyan szempontokat veszünk számításba, mint a lekérdezés, az absztrakció problémává válik.
Végül, ahogy Mark Baker egyszer fogalmazta: „A protokoll-függetlenség egy hiba, nem pedig egy kívánt jellemző.” Ez első hallásra furcsának tűnhet, de el kell azon gondolkodnunk, hogy a valódi protokoll-függetlenség megvalósíthatatlan, csak azt választhatjuk, hogy egy másik protokolltól függjünk, mely vagy azonos vagy egy különböző szinten helyzkedik el. Nem jelent problémát, ha egy olyan széleskörben elfogadott, hivatalosan szabványosított protokolltól függünk, mint például a HTTP. Ez különösen igaz akkor, ha ez a protokoll sokkal szélesebb körben elterjedt és támogatott, mint az az absztrakció, mely helyettesíteni próbálja.
5. Nincs gyakorlati, világos és konzisztent útmutatás arra vonatkozóan, hogy hogyan tervezünk REST-esített alkalmazásokat
Számos olyan szempontja van a REST-esített tervezésnek, ahol nincsenek hivatalosan bevált módszerek, és nincsenek szabványosított módjai annak, hogy a HTTP használatával hogyan oldjunk meg egy adott problémát oly módon, hogy az a REST elvekhez igazodjon. Nyilvánvaló, hogy ettől jobb helyzetet is el tudnánk képzelni. Mégis, a REST több alkalmazási koncepciót testesít meg, mint a WSDL/SOAP alapú webes szolgáltatások. Másszóval, jogosan kritizáljuk a REST-et, de az alternatívákra (melyek alapjában véve egyáltalán nem nyújtanak segítséget) ez méginkább vonatkozik.
Alkalmanként ez a kétely olyan formában merül fel, hogy azt mondjuk: „még a REST szakértők sem értenek egyet abban, hogy ezt hogyan lehet megvalósítani”. Ez általánosságban nem igaz. Ha alkalmunk van rá, megpróbálhatjuk, hogy mi a könnyebb: öt olyan SOA vagy pedig öt olyan REST támogatót találni, akik egyetértenek egy adott kérdésben? Múltbéli tapasztalat alapján inkább a REST-es csoport megegyezését valószínűsíthetjük.
Folytatás következik.