REST (Representational State Transfer): arhitektuur, põhimõtted ja näited

REST: selge juhend RESTful-arhitektuurist, põhimõtetest ja praktilistest näidetest — REST API, HTTP päringud, ressursiidentifikaatorid ja parimad praktikad arendajatele.

Representational State Transfer (REST) on programmeerimisarhitektuuri rakendamine, mille eesmärk on suurendada arvutisüsteemide kommunikatsiooni tõhusust ja skaleeritavust. REST põhineb ideel, et jagamine ja ligipääs suurtele andmemahtudele on kõige tõhusam siis, kui andmeid tehakse kättesaadavaks nõudmisel, edastades viiteid või tunnuseid andmete juurde, mitte pidevalt koguandmete koopiaid. RESTi rakendavaid süsteeme nimetatakse tavaliselt RESTful süsteemideks — need kasutavad selgelt määratletud ressursituvastust ja standardseid protokolle (näiteks HTTP), et võimaldada ühtset, iseloomulikku ning ennustatavat liidest kliendi ja serveri vahel.

RESTi põhimõtted ja olulised piirangud

• Client–server – kliendi ja serveri rollid on eraldatud: klient vastutab kasutajaliidese ja rakenduse staatuse hoidmise eest, server hoiab andmeid ja äriloogikat. See võimaldab sõltumatut arendust ja skaleerimist.
• Stateless (olekuta) – iga päring serverile peab sisaldama kõiki vajalikke andmeid selle töötlemiseks. Server ei säilita kliendi seanssi (state) päringute vahel, mis lihtsustab ressursside haldust ja parandab skaleeritavust.
• Cacheable (vahemällu sobivus) – vastused peavad olema kas vahemällu salvestatavad või mitte; õigesti kasutatud vahemälu vähendab latentsust ja koormust. HTTP pakub selleks standardseid päiseid (nt Cache-Control, ETag).
• Uniform interface (ühtne liides) – loomulik ja standardne viis ressursside identifitseerimiseks ja manipuleerimiseks. See hõlmab:
  • ressursside unikaalset identifitseerimist (URI),
  • ressursside muutmist nende esinduste kaudu (representation),
  • sõnumite enesekirjeldatavust (sõnumid sisaldavad piisavalt metaandmeid),
  • HATEOAS (hypermedia as the engine of application state) — kliendi navigeerimine rakenduse olekute vahel peaks olema võimalik hüperlinkide abil, mida server vastustes annab.
• Layered system (kihiline süsteem) – arhitektuur võib koosneda kihilistest teenustest (näiteks API gateway, autentimiskihid, vahemälud), mis klienti ei tohiks eraldi mõjutada.
• Code on demand (valikuline) – server võib ajutiselt kliendile saata koodi (näiteks JavaScripti), et laiendada klientide funktsionaalsust; see on RESTi piirangutest valikuline osa.

HTTP ja REST: meetodid, olekud ja esindused

REST rakendab tihti HTTP omadusi. Levinumad HTTP-meetodid ja nende semantika REST API-des:

• GET – ressurssi või selle nimekirja pärimine; peab olema idempotentne ja mitte-muutuv
• POST – uue ressursi loomine või alamoperatsioon, tavaliselt mitte-idempotentne
• PUT – täielik ressurssi asendamine; idempotentne
• PATCH – osaline ajakohastamine; tavaliselt mitte-idempotentne sõltuvalt implementeerimisest
• DELETE – ressurssi kustutamine; idempotentne

Disainipraktika ja parimad tavad

• URI-disain – ressursid peaksid olema selgelt ja loogiliselt identifitseeritavad: näiteks /products/123 või /users/45/orders. Väldi tegevuspõhiseid URIsid nagu /getUserInfo või /createOrder.
• Versioonihaldus – API versioone hoitakse kas URI-s (nt /v1/products) või päistes (Accept või custom header). Valik sõltub vajadustest ja tagasiside haldamisest.
• Paginatsioon, filtreerimine ja sorteerimine – suurematele andmekogumitele paku standardseid parameetreid (limit, offset, page, sort, filter), et vältida koormuse ja latentsuse probleeme.
• Turvalisus – kasuta HTTPS-i kogu andmevahetuseks; autentimiseks ja autoriseerimiseks kasuta turvaprotokolle nagu OAuth 2.0, JWT vms; piiritle juurdepääsu ja rakenda rate limiting.
• Caching – kasuta HTTP päiseid ja vahemälustrateegiaid, kui vastused on vahemällu sobivad; see vähendab latentsust ja serverikoormust.
• Dokumentatsioon ja leping – kirjuta selge API dokumentatsioon (nt OpenAPI/Swagger), et kliendid saaksid API-d iseseisvalt kasutada ja testida.
• Hälbe- ja veahaldus – tagasta selged, masinloetavad veateated (nt JSON-vormingus) koos sobiva HTTP-koodiga, et kliendid saaksid asjakohaselt reageerida.

Praktilised näited ja analoogiad

Näide mitte-RESTful reaalsest süsteemist oleks traditsiooniline kodune filmikogu. Selleks, et pääseda ligi mõnele filmile, peab raamatukogu omanik hankima selle füüsilise koopia. Selle tulemuseks on märkimisväärne raiskamine, kuna koopiaid on rohkem kui neid igal hetkel kasutatakse. Samuti on uute filmide lisamine raamatukokku üldiselt mittetriviaalne. Streaming-video on REST-väline vaste koduraamatukogule. Selle asemel, et iga filmi täielik koopia oleks kodus salvestatud, viidatakse filmile ainult selle pealkirja järgi ja filmi sisu voogedastatakse nõudmise korral.

World Wide Web on tänapäeval suurim näide RESTful-süsteemist. Füüsilised raamatukogud on selle mitte-RESTful ekvivalent. Selle asemel, et saata igale inimesele või raamatukogule iga digitaalse ressursi füüsiline elektrooniline koopia, anname igale ressursile URL-tunnuse "http://example.com", seejärel pääseme tegelikule sisule ligi Interneti kaudu, selle asemel et otsida optiliselt kettalt või kõvakettalt kohalikku koopiat.

REST-arhitektuuri saab rakendada ka muudes kontekstides. Võtame näiteks kaks ettevõtet, kes soovivad jagada mitu gigabaiti pidevalt muutuvat teavet. Nende andmebaaside täieliku koopia saatmine üksteisele (isegi interneti kaudu) on korrapäraselt raiskav ja aeganõudev protsess. Selline teabe jagamise meetod on sarnane eelnevalt toodud raamatukogu näitega. Selle asemel võivad ettevõtted jagada omavahel andmebaasi tunnuseid, võib-olla isegi määrata igale andmebaasi elemendile oma URLi. Kui üks ettevõte soovib andmebaasist pärida teisele ettevõttele kuuluva konkreetse kaubaartikli hinda, saab ta siis selle konkreetse inventariartikli kohta andmeid välja otsida.

Millal REST ei pruugi olla parim valik ja alternatiivid

REST on väga paindlik ja laialt kasutatav, kuid kõikide probleemide jaoks ei pruugi see olla parim. Näiteks:

• reaalajalised kahepoolsed ühendused (nt videokonverentsid, live-chats) — siin sobivad paremini WebSocketid;
• kus on vaja väga madalat latentsust ja tugevat binaarset RPC‑stiili — gRPC sobib paremini;
• kui kliendid vajavad paindlikku päringute kokkupanekut ühelt lõpppunktilt (nt eri kliendid tahavad erinevaid väli) — GraphQL võib pakkuda tihedamat ja kliendile sobivamat liidest.

Kokkuvõte

REST on lihtne, hästi mõistetav ja laialdaselt toetatud arhitektuuriline stiil, mis tugineb selgetele nüanssidele — ressursside identifitseerimine, standardsete HTTP-meetodite kasutamine, olekuta päringud ja vahemällu sobivus. Hästi disainitud RESTful API on ennustatav, lihtne dokumenteerida ja skaleeritav, kuid konkreetsete nõuete puhul — reaalaja, madala latentsuse või keerukate päringute korral — tasub uurida ka alternatiive nagu GraphQL, gRPC või WebSocketid.

Küsimused ja vastused

K: Mis on Representational State Transfer (REST)?

K: Kuidas nimetatakse RESTi rakendavaid süsteeme?

K: Kuidas arvutisüsteemid RESTi abil omavahel suhtlevad?

K: Mida REST dokumenteerib?

K: Kes lõi tarkvara arhitektuuristiili Representational State Transfer (REST)?

K: Millist tüüpi kommunikatsiooni kasutab REST?

K: Mis on Representational State Transfer (REST) eesmärk?

Otsing