REST (Representational State Transfer): kas tai ir kaip veikia

Sužinokite, kas yra REST, kaip veikia RESTful architektūra ir kodėl ji efektyvi duomenų dalijimuisi, API dizainui ir sistemų integracijai.

Atstovaujamosios būsenos perdavimas (angl. Representational State Transfer, REST) yra programavimo architektūros stilius, skirtas pagerinti komunikacijos ir duomenų keitimosi efektyvumą kompiuterinėse sistemose. REST idėja paprasta: vietoje pilnų duomenų kopijų dalijamasi nuorodomis (adresais) į tuos išteklius ir perduodamos jų reprezentacijos pagal poreikį. Sistemos, kurios laikosi šių principų, dažnai vadinamos „RESTful“.

Ką reiškia „išteklius“ ir „reprezentacija“?

Išteklis REST kontekste yra bet kas, ką galima identifikuoti – dokumentas, įrašas duomenų bazėje, vaizdo įrašas ar paslauga. Ištekliai paprastai turi unikalų identifikatorių (URI). Reprezentacija yra to išteklių turinio formatas, kurį klientas gauna arba siunčia: dažniausiai JSON, XML arba HTML. Reprezentacija gali apimti tik tam tikrą išteklių dalį arba metaforą su nuorodomis į papildomus išteklius (HATEOAS).

Pavyzdžiai

Realaus pasaulio ne RESTful sistemos pavyzdys galėtų būti tradicinė namų filmų kolekcija. Norėdamas gauti prieigą prie bet kurio filmo, bibliotekos savininkas turi gauti fizinę jo kopiją. Dėl to susidaro nemažai atliekų, nes egzistuoja daugiau kopijų, nei bet kuriuo metu naudojama. Be to, norint papildyti biblioteką naujais filmais, paprastai reikia skirti daug laiko. Vaizdo transliacijos yra namų bibliotekos REST atitikmuo. Vietoj to, kad namuose būtų saugoma visa kiekvieno filmo kopija, filmas nurodomas tik pavadinimu, o filmo turinys transliuojamas pagal pareikalavimą.

Pasaulinis žiniatinklis šiandien yra didžiausias RESTful sistemos pavyzdys. Fizinės bibliotekos yra jos ne RESTful atitikmuo. Užuot siuntę kiekvieno skaitmeninio ištekliaus fizinę elektroninę kopiją kiekvienam asmeniui ar bibliotekai, kiekvienam ištekliui priskiriame URL identifikatorių "http://example.com", tada tikrąjį turinį pasiekiame internetu, užuot gavę vietinę kopiją iš optinio disko ar kietojo disko.

REST architektūrą galima taikyti ir kitais atvejais. Pavyzdžiui, apsvarstykite dvi įmones, kurios nori dalytis kelių gigabaitų informacija, kuri nuolat kinta. Nuolat siųsti viena kitai visą savo duomenų bazių kopiją (net internetu) yra neekonomiškas ir daug laiko reikalaujantis procesas. Vietoj to įmonės gali dalytis duomenų bazių ID arba priskirti atskirus URL adresus kiekvienam duomenų elemento, ir kai viena bendrovė nori sužinoti tam tikros prekės kainą, ji užklausia tik reikiamo inventoriaus vieneto reprezentacijos.

Pagrindiniai REST principai (konstraints)

• Client–server: aiški atsakomybės atskirtis tarp kliento (naudotojo sąsaja) ir serverio (duomenų saugojimas bei apdorojimas).
• Stateless (be būsenių): kiekviena užklausa turi būti savarankiška – serveris neturi saugoti kliento sesijos duomenų tarp užklausų.
• Cacheable: atsakymai gali būti talpinami (cache), kad būtų sumažintas tinklo eismas ir pagerintas našumas.
• Uniform interface: vienodas būdas identifikuoti ir manipuliuoti ištekliais (URI, standartinės HTTP operacijos, reprezentacijos).
• Layered system: sistema gali būti sudaryta iš sluoksnių (pvz., tarpiniai serveriai, saugyklos) be kliento žinojimo apie kitus sluoksnius.
• Code on demand (neprivaloma): serveris gali laikinai perduoti vykdomą kodą klientui (pvz., JavaScript), kad išplėstų kliento funkcionalumą.

Dažniausiai naudojamos HTTP operacijos

• GET – gauti išteklių reprezentaciją (saugus, idempotentinis).
• POST – sukurti naują išteklių arba pateikti duomenis apdorojimui (dažnai nėra idempotentinė).
• PUT – atnaujinti arba sukurti išteklių nurodytu URI (idempotentinis).
• DELETE – ištrinti išteklių (idempotentinis).
• PATCH – iš dalies atnaujinti išteklių (ne visada idempotentinis, priklauso nuo implementacijos).

Reprezentacijos ir turinio derinimas

Reprezentacijos formatai dažniausiai yra JSON arba XML, bet taip pat gali būti HTML, vaizdai, PDF ir kt. Klientas ir serveris derina formatą per HTTP antraštes (Accept, Content-Type). JSON tapo praktiškai standartu REST API dėl paprastumo ir suderinamumo su JavaScript.

Bendri HTTP atsakymų kodai

• 200 OK – užklausa sėkminga.
• 201 Created – sėkmingai sukurtas išteklius.
• 204 No Content – sėkmingai apdorota, be atsakymo turinio.
• 400 Bad Request – neteisinga užklausa.
• 401 Unauthorized – reikalinga autentifikacija.
• 403 Forbidden – klientas neturi teisių.
• 404 Not Found – išteklius nerastas.
• 409 Conflict – konfliktas (pvz., versijų konfliktas).
• 500 Internal Server Error – serverio klaida.

HATEOAS (Hypermedia as the Engine of Application State)

Vienas iš REST principų yra tai, kad išteklio reprezentacija gali apimti nuorodas (hipermediją) į susijusius veiksmus ar išteklius. Tai leidžia klientui sužinoti, kokius veiksmus galima atlikti toliau, neįkoduojant visos logikos kliento pusėje.

Geriausios praktikos

• Naudokite daiktavardžius (nouns) URI: /users, /orders/123, o ne veiksmažodžius.
• Užtikrinkite idempotentiškumą, kai tai pravartu (PUT, DELETE).
• Versijuokite API (URI /v1/, arba per antraštes), kad išsaugotumėte suderinamumą.
• Taikykite talpinimą (HTTP Cache-Control, ETag) našumui pagerinti.
• Suteikite aiškius, struktūruotus klaidų pranešimus (kodas, žinutė, detalės).
• Apribokite atsakymų dydį per puslapiavimą (pagination) ir filtravimą.
• Naudokite HTTPS ir saugią autentifikaciją (API raktai, OAuth, JWT).
• Suteikite rate limiting ir logging mechanizmus, kad apsaugotumėte nuo per didelio srauto.

Trūkumai ir alternatyvos

Nors REST yra labai populiarus, jis ne visada yra geriausias pasirinkimas. Trūkumai gali būti:

• Perdėtas tinklo srautų skaičius (klientas turi atlikti kelias užklausas, kad surinktų susijusią informaciją).
• Standartinė struktūra kartais verčia siųsti perteklinę informaciją arba atlikti papildomas užklausas.

Alternatyvos: GraphQL leidžia klientui tiksliai užklausti reikiamų laukų per vieną užklausą; gRPC gali būti efektyvesnis tarp mikroservisų ryšiui su binariniais protokolais ir stipria tipizacija.

Kada naudoti REST?

REST tinka, kai norite paprasto, lankstaus ir plačiai palaikomo sprendimo internetinėms API, ypač kai reikia suderinti daugelio klientų poreikius (web, mobilios programėlės). Jei reikia labai dinamiškų užklausų struktūrų arba žymiai sumažinti tinklo užklausų skaičių, verta apsvarstyti ir kitas technologijas, pvz., GraphQL.

Apibendrinant: REST yra architektūrinis stilius, grindžiamas išteklių identifikavimu per URI ir standartinėmis HTTP operacijomis. Jis supaprastina duomenų prieigos modelį, leidžia naudoti talpinimą bei saugo kliento ir serverio atsakomybės atskirtį — todėl tapo pagrindine daugumos šiuolaikinių API kūrimo praktika.

Klausimai ir atsakymai

K: Kas yra reprezentacinės būsenos perdavimas (REST)?

K: Kaip vadinamos sistemos, kuriose įdiegtas REST?

K: Kaip kompiuterių sistemos bendrauja tarpusavyje naudodamos REST?

K: Ką REST dokumentuoja?

K: Kas sukūrė programinės įrangos architektūros stilių REST (Representational State Transfer)?

K: Kokio tipo ryšys naudojamas REST?

K: Koks yra REST (Representational State Transfer) tikslas?

Paieška pagal raidę