 Tiesa apie REST Pastaba: šis tekstas daugiausia orientuotas į programuotojus, tad daugelis sąvokų laikomos akivaizdžiomis ir smulkiai neaiškinamos. Tikriausiai kažkiek sujaukia mintis, kai kažkas netikėtai tampa populiariu dalyku. Matyt populiarumas ir buvo priežastis to, kas daroma neteisingai, su REST (Representional State Transfer). Kas tai ir kokie jo apribojimai? Kas tai yra? Pirmiausia gali pasirodyti, kad REST yra visai paprastas dalykas URL panaudojimas kviečiant nutolintas procedūras. Ir iš tikro tai sudaro 80% RESTo. Panaudodami RPC (remote procedure calls) galime sukurti kiek tik norime komandų tokiu pavidalu: Jas bet kurią programavimo kalbą galima išversti kaip: Metodus galima panaudoti įrašų įrašymui, koregavimui, šalinimui ir bet kokiems kitiems veiksmams atlikti. Gražinamas rezultatas gali būti HTML, XML, Jason ar bet kokiu kitu, tame tarpe ir savu, formatu. Metodus galima realizuoti Java, .Net, PHP ar bet kokia kita norima kalba. RPC dažnai vadinamas routing, tačiau iš tikro yra dar nuo CGI. Tačiau kai tik tuos metodus padarote viešais, prasideda betvarkė. Tad REST bando įvesti tam tikrą RPC naudojimo struktūrą (kitaip tariant taisykles). Pirma taisyklė: URL turi perteikti tik resursus, t.y. URL yra tarsi adresas į tam tikrą daiktą (t.y., duomenis). Tad kaip galime nurodyti komandas? Antra taisyklė: komandos nurodomos tik panaudojant 4-ias pagrindines HTTP komandas: GET,
PUT, POST ir DELETE.
Pagrindinis principas kad internetas yra labai platus, o jo taikymai turi atrodyti tarsi standartinės tranzakcijos. Aiškinama, kad HTTP infrastruktūra žino, kaip tvarkyti tuos elementus kešuojant, autorizuojant ir pan. Kam išradinėti ratą, jei jį jau turime? Pastaba: dažnai aptariant REST aiškinama, kad GET ir DELETE yra nieko nekeičiantys, t.y., juos panaudojus kelis kartus nėra pasikeitimų (išmestas resursas pakartotinai metamas lieka išmestu). Tačiau juk realioje aplinkoje GET nėra nieko nekeičiantis (ypač, kai kviečiami dinaminiai puslapiai , kuriuose yra skaitliukai, laiko nurodymai ir kiti kintantys dalykai). Filosofiškai PUT ir POST yra labai panašūs (nes POST irgi galima panaudoti resurso įrašymui). Jie skiriasi tik tuo, kad PUT nieko nekeičia, nes kelis kartus įrašius tą patį resursą, niekas nesikeičia. Tačiau REST tą skirtumą padidina, reikalaudamas, kad PUT visada būtų siejamas su URLu į kuriamą ar atnaujinamą resursą, tuo tarpu POST, jei jį gražina kaip rezultatą, turi nurodyti naują URL. Tad jei norite prisilaikyti REST, galite laikytis tokios nuostatos (atskiram įrašui ar visam įrašų rinkiniui),
pvz. Užbaigianti REST komponentė paprastai apibūdinama kaip hipermedija kaip būsenos variklis. Skamba paslaptingai, tačiau tai tereiškia nuorodas į kitus žingsnius. Jei norite griežtai laikytis REST ir sprendimą turėti kliento pusėje, išeitimi gali būti Ajax JQuery Ajax palaiko visas Tačiau iš tikro pats Ajax yra būsenas turintis klientas ir jame REST nelabai tinkamas. Tačiau yra dar viena problema: metodus galite kviesti tik iš to paties serverio (domeno). Tačiau negalima kreiptis į kitus domenus (nei yra www puslapis). O tai iš tikro rimtai apriboja REST API naudojimą. Aišku, yra daug šio apribojimo apėjimų (HTML5 vidiniai pranešimai puslapyje, JSONP, CORS ir tokios bibliotekos, kaip XDM), tačiau tai jau nebus elegantiški griežti REST sprendimai. Tad tėra vienas praktinis būdas naudoti REST API iš kito domeno susikurti proxy, t.y., serveryje pasirašote tam tikrą kodą, kuris užklausas iš Ajax nukreipia į kitus domenus. Vėlgi ne elegantiška, nesaugu ir nelabai gražu. Tai ką daryti? Prisiminti, kad REST nėra vienintelis pasirinkimas. Ankstesnės "Advanced HTML" skyrelio temos:
| |
