Estatu Ordezkaritzaren Transferentzia

Estatu Ordezkaritzaren Transferentzia (ingelesez representational state transfer) edo REST sistema hipermedioetarako software-arkitekturaren estilo bat da, World Wide Web, esaterako. Artikulu honetan REST teknologiaren historia, beste teknologien aurka nola portatzen den eta bere abantailak aurkeztuko dira. Baita ere bere ezarpen publikoak.

Terminoa 2000. urtean sortu zen, Roy Fieldingek, HTTP protokoloaren zehaztapenaren egile nagusietako batek, webguneari buruz idatzitako doktoretza-tesi batean, eta garapen-komunitateak asko erabili du.

Historia

Webgunea 1993-4 urteetan hasi zen egunero erabiltzen, eta orduan hasi ziren erabilera orokorreko webguneak eskuragarri jartzen. Une horretan, web arkitekturaren deskribapen zatikatu bat baino ez zegoen, eta presioa zegoen industrian web interfazearen protokoloetarako estandarren bat adosteko. Adibidez, hedapen esperimental batzuk gehitu zitzaizkion komunikazio-protokoloari (HTTP) proxiak onartzeko, eta hedapen gehiago proposatzen ari ziren, baina web-arkitektura formal baten beharra zegoen, aldaketa horien eragina ebaluatzeko.

Elkarrekin, W3C eta IETFko lantaldeak webeko hiru estandar nagusien deskribapen formalak sortzen hasi ziren: uri, HTTP eta HTML. Roy Fieldingek estandar horien sorreran parte hartu zuen (zehazki, HTTP 1.0 eta 1.1, eta URI), eta hurrengo sei urteetan REST estilo arkitektonikoa garatu zuen, webgunearen protokolo-estandarretan zituen murrizketak probatuz eta hobekuntza arkitektonikoak zehazteko eta desdoitze arkitektonikoak identifikatzeko bitarteko gisa erabiliz. Fieldingek REST definitu zuen 2000ko doktorego-hitzaldian, "Arkitektura estiloak eta sareetan oinarritutako software-arkitekturen diseinua" UC Irvine-n.

Deskribapena

REST terminoa hasieran arkitektura-printzipioen multzo bati buruzkoa bazen ere — beherago deskribatutakoak —, gaur egun zentzurik zabalenean erabiltzen da sistemen arteko edozein interfaze deskribatzeko, datuak lortzeko HTTP zuzenean erabiltzen duena edo datuen gaineko eragiketak edozein formatutan (XML, JSON, eta abar) egin direla adierazteko, mezuen elkartrukearen ereduetan oinarritutako protokoloen abstrakzio gehigarririk gabe, adibidez, AP. Web zerbitzuen sistemak Fielding-en REST arkitektura estiloaren arabera diseina daitezke, eta XMLHTTP interfazeak urruneko prozedurara deitzeko estiloaren (RPC) arabera ere diseina daitezke, baina SOAP erabili gabe. REST terminoaren bi erabilera desberdin horiek nolabaiteko nahasmena sortzen dute eztabaida teknikoetan, nahiz eta RPC ez den RESTen adibide bat. Restek dio webguneak eskalagarritasuna izan duela funtsezko diseinu batzuen ondorioz:

• Egoerarik gabeko bezero/zerbitzari protokolo bat: HTTP mezu bakoitzak eskaera ulertzeko behar den informazio guztia jasotzen du. Ondorioz, bezeroak eta zerbitzariak ez dute mezuen arteko komunikazioen egoerarik gogoratu behar. Hala ere, praktikan, HTTPn oinarritutako aplikazio askok cookieak eta saioaren egoera mantentzeko beste mekanismo batzuk erabiltzen dituzte (praktika horietako batzuk, URLen berridazketa kasu, RESTek ez ditu onartzen).
• Ondo definitutako eragiketa-multzo bat, informazio-baliabide guztiei aplikatzen zaiena: HTTP berez, eragiketa-multzo txiki bat definitzen du; garrantzitsuenak POST, GET, PUT eta DELETE dira. Askotan, eragiketa horiek datu-baseetako CRUD eragiketekin parekatzen dira (CLAB gaztelaniaz: sortu, irakurri, eguneratu, ezabatu), datuak iraunarazteko behar direnak, nahiz eta POST ez den zehazki eskema horretan sartzen.
• Baliabideak identifikatzeko sintaxi unibertsala. REST sistema batean, baliabide bakoitza bere URIaren bidez baino ezin da bideratu.
• Hipermedioak erabiltzea, bai aplikazioaren informaziorako, bai aplikazioaren egoera-trantsizioetarako: REST sistema batean egoera hori irudikatzea HTML edo XML izan ohi da. Horren ondorioz, posible da REST baliabide batetik beste askotara nabigatzea, estekak jarraituz soilik, erregistroak edo beste azpiegitura gehigarri bat erabiltzea eskatu gabe.

Baliabideak

RESTen kontzeptu garrantzitsu bat baliabideak egotea da (informazio-elementuak), identifikatzaile global bat erabiliz eskura daitezkeenak (Baliabidearen Identifikatzaile Uniforme bat). Baliabide horiek manipulatzeko, sareko osagaiak (bezeroak eta zerbitzariak) interfaze estandar baten bidez komunikatzen dira (HTTP) eta baliabide horien irudikapenak trukatzen dituzte (deskargatzen eta bidaltzen diren fitxategiak) - Eztabaidagarria da, hala ere, baliabideen eta haien irudikapenen arteko bereizketa platonikoegia ote den sarean modu praktikoan erabiltzeko, nahiz eta RDF komunitatean ezaguna izan.

Eskaera edozein konektore-zenbakik transmiti dezake (adibidez, bezeroak, zerbitzariak, katxeak, tunelak, etab.), baina bakoitzak bere eskaeratik "haratago ikusi" gabe egiten du (stateless (estaturik gabea) bezala ezagutzen dena, RESTen beste murrizketa bat, sareen eta informazioaren arkitekturaren beste zati askorekin bat den printzipio bat). Horrela, aplikazio batek baliabide batekin elkarreragin dezake, baliabidearen identifikatzailea eta eskatutako ekintza ezagututa, eta ez du jakin behar katxerik, proxyrik, suebakirik, tunelik edo beste edozer gauza dagoen haren eta informazioa gordetzen duen zerbitzariaren artean. Aplikazioak, ordea, itzulitako informazioaren formatua (irudikapena) jaso behar du, hau da, HTML edo XML dokumentu bat, nahiz eta irudi bat edo beste edozein eduki ere izan daitekeen.

REST RPC aurrean

REST web-aplikazio batek diseinu-ikuspegi desberdina behar du RPCn oinarritutako aplikazioarekin alderatuta (urruneko prozedurarako deia). RPCn, protokoloko edo aditzetako eragiketen aniztasunean jartzen da enfasia; adibidez, RPC aplikazio batek honako eragiketa hauek defini ditzake:

• getUser()
• addUser()
• removeUser()
• updateUser()
• getLocation()
• addLocation()
• removeLocation()
• updateLocation()
• listUsers()
• listLocations()
• findLocation()
• findUser()

RESTen, aldiz, baliabideetan edo substantiboetan jartzen da enfasia, batez ere baliabide-mota bakoitzari ematen zaizkion izenetan. Adibidez, REST aplikazio batek baliabide mota batzuk defini ditzake izen hauek emanez:

• Erabiltzailea {}
• Kokapena {}

Baliabide bakoitzak bere identifikatzailea izango luke, hala nola http://www.example.org/locations/us/ny/new_york_city. Bezeroek baliabide horiekin lan egingo lukete HTTP eragiketa estandarren bidez, hala nola GET baliabidearen kopia bat deskargatzeko. Ikus dezagun objektu bakoitzak bere URL propioa duela eta erraz miatu, kopiatu eta gorde daitekeela markatzaile gisa. Post albo-efektuak dituzten ekintzetarako erabiltzen da normalean, hala nola erosteko agindu bat bidaltzeko edo bilduma bati zenbait datu gehitzeko.

Adibidez, erabiltzaile batentzako erregistroak honako itxura hau izan dezake:

<erabiltzailea>
  <izena><izena/>
  <sexua><sexua/>
  <kokapena href="http://www.example.org/locations/us/ny/new_york_city"><kokapena/>
</erabiltzailea>

Erabiltzailearen kokapena eguneratzeko, REST bezero batek aurreko XML erregistroa deskargatu ahal izango luke lehenik, GET erabiliz. Ondoren, bezeroak fitxategia aldatuko zuen kokapena aldatzeko eta zerbitzarira igoko zuen HTTP PUT erabiliz.

Ohartu, ordea, HTTP aditzek (POST, GET, PUT, DELETE) ez dutela mekanismo estandarrik ematen baliabideak aurkitzeko -- ez dago LIST edo FIND eragiketarik HTTPn, RPC adibidean list* () eta find* () eragiketekin bat datozenak. Horren ordez, REST datuetan oinarritutako aplikazioek arazoa ebazten dute bilaketa-emaitzen bilduma bat beste baliabide mota gisa erabiliz, eta, horretarako, aplikazioaren diseinatzaileek URL gehigarriak ezagutu behar dituzte baliabide mota bakoitza erakusteko edo bilatzeko.

Adibidez, http://www.example.org/locations/us/ny/URLari buruzko GET HTTP eskaera batek esteka bat itzul lezake XMLko fitxategi-zerrenda batera, New Yorkeko lokalizazio posible guztiekin; aldiz, GET eskaera batek http://www.example.org/users? Surname = Michaels URLari eginez gero, lotura-zerrenda bat itzul liezaieke Michaels abizena duten erabiltzaile guztiei ".

Rest zenbait jarraibide ematen ditu ekintza horiek nola egin jakiteko, "Hipermedia, aplikazioaren egoera-bitarteko gisa" murrizketaren zati gisa, eta horrek iradokitzen du formulario-lengoaia bat erabiltzea (HTML formulario bat, adibidez) kontsulta parametrizatuak zehazteko.

A9.com-en OpenSearch ekimena bilaketak estandarizatzen saiatzen da REST erabiliz, REST-en oinarritutako sistemekin erabiltzeko baliabideak eta formatu generikoa aurkitzeko zehaztapenak ezarriz, RDF, XTM, Atom, RSS (hainbat formatan) eta XML XLink-ekin estekak kudeatzeko.

Hasiera

Roy T. Fieldingek 2000. urteko jatorrizko hitzaldian honela definitzen du REST: "... hipermediako sistema banatuetarako arkitektura-estiloa, RESTek gidatzen dituen software-ingeniaritzaren printzipioak eta printzipio horiek atxikitzeko aukeratutako interakzio-konstanteak deskribatuz...". Hona hemen printzipio horiek:

1. Bezero-zerbitzari arkitektura. Erantzukizunak bereiztea eta eramangarritasuna azpimarratzen ditu. Zenbat eta gutxiago ezagutu bezeroaren gaineko zerbitzaria, orduan eta desakoplatuagoa dago haren interakzioa, eta errazagoa da osagaiak aldatzea. Definizioz, REST sistema banatu zentralizatuekin funtzionatzeko diseinatutako arkitektura da, zerbitzari bat nodo nagusi gisa erabiltzen ez dutenen aurka – Adibidez, berdinen arteko arkitektura edo P2P –.
2. Egoerarik eza. Egoera bezeroan gorde eta mantentzen da, eta ez zerbitzarian. Hau da, eskaerek egoerarik ez duen zerbitzari batean egin ahal izateko behar den informazio guztia eman behar dute, eta, beraz, ez du bezero berarentzako deien arteko testuingururik gordetzen. Horrek ez du esan nahi zerbitzariak ezin duenik testuinguruz aldatu eta bezeroari trantsizio hori erraztu. Hori lortzeko, normalean eskaeren birhelbideak erabiltzen dira; horrela, bezeroak eskaera bakarra egingo du eta zerbitzariak endpoint edo baliabide batean prozesatuko du, eta beste bati bidaliko dio prozesatzen jarraitzeko. Hori modu gardenean gertatzen da bezeroarentzat, eta ohikoa da, adibidez, erregistroarekin lotutako erabilera-kasuetan eta saio automatikoaren hasieran: zerbitzariak kontua sortzen du, saio-token bat sortzen du eta, bezeroari itzuli beharrean, hark login-URIra dei dezan – Horrek denborak handituko lituzke, eskaera bakoitza garestia baita bezeroentzat –, azken saioa hasteko endpoint horretara bidaltzen du, azken erantzuna bera ikusita.
3. Katxea gaitzea eta erabiltzea. Eskaera guztiek adierazi behar dute miagarriak diren ala ez; hori egiteko modu estandar bat HTTPren kontrol-erregistroaren goiburukoak dira. Horrela, erantzun miatuak bidal daitezke sareko edozein puntutatik, eskaera zerbitzarira iritsi beharrik gabe. API dinamikoaren kasuan horrek zentzurik ez duela dirudien arren, datu aldaezinen kasuetan kostuak aurreztu ditzake, hala nola definizioetan.
4. Geruzakako sistema. Arestian aipatutako erantzukizun-banaketarekin du zerikusia, eta ezartzen du bezero batek soilik jakin behar duela zein geruzari buruz ari den hizketan. Hau da, ez ditu kontuan hartu behar alderdi zehatzak, hala nola erabilitako datu-basearen berezitasunak, edo tartean dauden katxeak, proxiak edo karga-balantzatzaileak. Segurtasuna behar izanez gero, web-zerbitzuen gainean gehitu behar da, logika eta segurtasuna bereizita egon daitezen.
5. Interfaze uniformea.
   1. Eskaeretan baliabideak identifikatzea. Orri honen deskribapenean adierazten den bezala, eskaerek banakako baliabideak identifikatzen dituzte. Hala ere, RESTek azpimarratzen du baliabideak kontzeptualki bereizita daudela zerbitzariak itzultzen dituen irudikapenetatik (HTML, XML, JSON...). Formatu mota HTTP goiburuetan zehaztu daiteke, eta edukiaren negoziazioaren bidez, zerbitzaria eta bezeroa ados jar daitezke lehenak aginduko duen eta bigarrenak espero duen erantzunarekin.
   2. Baliabideak irudikapenen bidez manipulatzea. REST espezifikazioa eskaerak ahal den guztian aurrezten saiatzen da. Horregatik, bezero batek baliabide baten ordezkaritza duenean, erantsitako edozein metadatu barne, nahikoa informazio du baliabidearen egoera aldatzeko edo ezabatzeko. Hau da, RESTek sustatzen dituen tresnen bidez (auto-dokumentatutako API erabiltzea, deskribatzailea, HTTP aditzak...), bezeroak jakin dezake GET batekin jasotako baliabide baten gainean edozein eragiketa egitearen emaitza aurreikusten.
   3. Mezu auto-deskriptiboak. Mezu auto-deskribatzaile baten ideia da bezeroak ulertzeko behar duen informazio guztia edukitzea. Beraz, ez litzateke informazio gehigarririk egon behar dokumentazio bereizi batean edo beste mezu batean.
   4. Hipermedia aplikazioaren egoeraren motor gisa (HATEOAS ingelesezko siglengatik, Hypermedia As The Engine of Application State). Aplikazioaren hasierako URIan sartu ondoren, REST bezero batek gai izan beharko luke zerbitzariak dinamikoki hornitutako estekak erabiltzeko, behar dituen baliabide erabilgarri guztiak aurkitzeko. Prozesuak aurrera egin ahala, zerbitzariak gaur egun erabilgarri dauden beste baliabide batzuetarako estekak dituen testuarekin erantzuten du. Horrek ezabatu egiten du bezeroak aplikazioaren egiturari edo erreferentzia dinamikoei buruzko informazioa (hard-kodeatua) kodean idatzita izateko beharra.

Gidalerro horien hedaduragatik eta proiektu bakoitzaren berezitasunengatik (negozio-eremua eta API), zaila izan daiteke RESTek deskribatzen dituen printzipio guztiak zehaztapen berean bateratzea. Hori dela eta, Richardsonen heldutasun-ereduak API REST espezifikazio batek zer mailatatik igarotzen duen deskribatzen du, sortzen denetik kontrol hipermedioak eskuratuz hobetzen den arte. Hauek dira mailak:

1. 0. maila. Zerbitzuek URI bakarra dute, zerbitzuak onartutako eragiketen maila osoa onartzen duena, gutxi definitutako baliabideekin. Ez da API RESTful bat.
2. 1. maila. Baliabideak sartzen ditu eta banakako URIei eskaerak egiteko aukera ematen du, ekintza bereizietarako, sarbide-puntu unibertsal bat azaldu beharrean. Baliabideak orokortuta daude oraindik, baina eremu zehatzago bat identifika daiteke. Lehen maila ez da RESTful, baina izateko gaitasuna lortzera bideratuta dago.
3. 2. maila. Sistema HTTP aditzak erabiltzen hasten da. Horrek espezializazio handiagoa ahalbidetzen du, eta, oro har, baliabideak bitan banatzen dira: batean datuak bakarrik lortzeko (GET) eta bestean datuak aldatzeko (POST), nahiz eta granularitate handiagoa ere posible den. Baliabide bakoitzeko GET eta POST eskaera bat baino gehiago dituen banatutako sistema bat hornitzearen desabantailetako bat sistemaren konplexutasuna handitzea izan daiteke, nahiz eta APIko bezeroen datuen kontsumoa neurri handi batean sinplifikatu egiten den.
4. 3. maila. Azken mailak irudikapen hipermedioa sartzen du, HATEOAS ere deitua. Irudikapen hori baliabideen erantzun-mezuetan txertatutako elementuen bidez egiten da. Elementu horiei esker, eskaera bidaltzen duen bezeroak datu-entitate indibidualen arteko harremana ezar dezake. Adibidez, hotel baten erreserba-sistema bati GET eskaera eginez gero, logela guztien kopurua itzul daiteke, logela espezifikoak erreserbatzeko aukera ematen duten estekekin batera.

SOAPekiko desberdintasunak

REST arkitektura batez ere datuetan (baliabideak) zentratuta dagoen bitartean, SOAP protokoloa erabiltzen duen arkitektura datu horiekin jarduteko aukera ematen duten zerbitzuetara bideratzen da. Askotan, SOAP beste arkitektura mota bat dela pentsatzearen errorean eror daiteke; hala ere, izenak adierazten duen bezala, protokolo bat da, eta, beraz, inplementazio posiblea gehiago murrizten du, eta, horren truke, estandarizatuagoa dago. Horrek garrantzi berezia du zerbitzariek bidaltzen edo jasotzen dituzten mezu-motetan: REST bezeroek, oro har, HTML edo XML sistemetan bidaltzen dute informazioa; SOAP bidezko inplementazio bat, berriz, azkenaren alde egiten da normalean; tipatutako hizkuntza sendoa du, JSON baino hitzezkoagoa – REST arkitekturak inplementatzen dituzten zerbitzuetan oso hedatua –, eta transmisio bidezko banda-zabalera handiagoa eskatzen du.

Bestalde, REST zerbitzuak nabigatzaile baten bidez probatu ahal izan behar dira RESTful izan ahal izateko, eta, beraz, zerbitzuak berak kontrolatu behar du makinentzat lagunkoia den eduki bat edo testuinguruaren arabera gizakientzat irakurgarria den aurkezpen bat itzultzen duen. SOAPen inplementazio bat probatzeko, beharrezkoa da ad-hoc tresnak erabiltzea, hala nola SoapUI. Gainera, liburutegien erabilera hedatuago dago azken aukera horretan, eta REST baliabideak irudikatzen dituzten URIetarako soilik erreserbatuta geratzen da, lehen deskribatu den bezala.

Rest irakurketa-printzipioan oinarritzen da, eragiketa ohikoena baita; beraz, eskaera gehienak GET motakoak izango dira; SOAP, berriz, POST eskaerekin eraikiagoa dago. Azken hori eta baliabide ez-espezifikoak direla eta, SOAPek bezero konplexuagoak garatzea ekar dezake, REST zerbitzuekin eraiki daitezkeenak baino.

Abantailak eta eragozpenak

Proposamen arkitektoniko oro bezala, hura modu holistikoan ebaluatu behar da, inplementatzeak ekar ditzakeen onura-kostuen balantzeari dagokionez. Egia da gaur egun APIen zati handi bat – Bereziki publikoak edo hirugarrenek kontsumitzeko irekiak – REST edo RESTful izateko diseinatzen direla, eta, beraz, programatzaileetan nolabaiteko adostasuna dago zer espero den jakiteko; hala ere, SOAP protokoloaren estandarizazioak, ezarpen-mailan, erraza egiten du RESTen irekita geratzen diren erabaki asko alde batera uztea. Bestalde, URI publikoek duten ikuspena segurtasun-arazo bat izan daiteke, parametroen gehieneko luzerak eragindako muga teknikoez gain. Azken hori SOAPek ohiko moduan gomendatzen dituen POST eskaeren bidez konpon daiteke, eta bereziki baliagarria da informazio edo datu bitar asko bidaliz gero. Oro har, REST bezeroan eta zerbitzarian ezartzeko soluzio errazagoa izan daiteke, framework askorekin, out-of-the-box lehenetsita, Djangoren kasuan bezala. Hala ere, SOAPek ezarpen-xehetasunei buruzko erabakiak aurreztu ditzake eta eragiketak modu gardenagoan eskaini bezeroari, datuen abstrakzioen ordez, endpoint jakin batean eskuragarri dauden zerbitzu zehatzak argitaratuz.

Ezarpen publikoak

RESTren definizioa oso zabala denez, esan daiteke REST aplikazio ugari daudela sarean (ia edozer gauza eskuragarri HTTP GET eskaera baten bidez). Modu murriztaileagoan, web zerbitzuei eta RPCari kontrajarrita, REST webaren hainbat arlotan aurki daiteke:

• Blogosfera -blogen unibertsoa-, gehienbat, RESTen oinarrituta dago, XML fitxategiak deskargatzea baitakar (RSS edo Atom formatuetan), beste baliabide batzuetarako esteken zerrendak dauzkatenak.
• Amazon.com-ek garatzaileentzako interfazea eskaintzen du REST formatuan zein SOAP formatuan (REST bertsioa da trafiko handiena jasotzen duena).
• EBayk 2008ra arte REST interfaze bat eskaini zuen garatzaileentzat.
• Kanadako Gobernuaren "Seniors Canada On-line" proiektuak hemen deskribatutako REST interfazea eskaintzen du.
• Bloglines-ek REST-en oinarritutako API bat eskaintzen du garatzaileentzat.
• Yahoo! Ek API bat eskaintzen du RESTen garatzaileentzat.
• Ruby on Rails bideratzeko mekanismoak REST aplikazioak jasaten ditu, MVC diseinu-patroia erabiliz.
• Microsoftek ADO.NET Data Services Framework-en du bere inplementazioa (lehenago "Astoria" bezala ezagutua) [1].
• Catalyst-en mekanismo berak MVC bidezko REST aplikazioak ere onartzen ditu.
• Zopeko objektuen argitaratzailea.
• Javarako REST inplementazioa: RestLet.
• Facebookek RESTen oinarritutako API bat eskaintzen du.
• Twitterrek RESTen oinarritutako API bat eskaintzen du.
• Megak RESTen oinarritutako API bat eskaintzen du.
• Merkatu Libreak RESTen oinarritutako API bat eskaintzen du garatzaileentzat.
• OpenNebulak, JSON eta REST formatuen bidez, elkarri konektatutako makina birtualen artean zerbitzuak sortu, kontrolatu eta monitorizatzeko aukera ematen du.

Ziur asko antzeko beste inplementazio asko egongo dira.

Nolanahi ere, kontuan izan behar da goian deskribatutako inplementazio asko ez direla RESTful erabat, hau da, ez dituztela REST arkitekturak ezartzen dituen murrizketa guztiak errespetatzen. Hala ere, guztiak RESTen inspiratuta daude eta arkitekturaren alderdirik esanguratsuenak eta murriztaileenak errespetatzen dituzte, bereziki "interfaze uniformearen" murrizketa. Zerbitzu horiei "ustekabean RESTful" deitu zaie.

Ikus, gainera

• XML
• Web-zerbitzua