Kaj je REST – prenos predstavitvenega stanja: definicija in primeri

Prenos predstavitvenega stanja (REST) je programska arhitekturna zasnova za zanesljivo, preprosto in učinkovito komunikacijo v računalniških sistemih. Uteleša idejo, da je najučinkovitejši način izmenjave večjih količin podatkov med številnimi odjemalci ta, da so podatki na voljo na zahtevo prek referenc (identifikatorjev virov), ne pa z razpošiljanjem celotnih kopij. Sistemi, ki spoštujejo načela REST, imenujemo »RESTful« sistemi.

Primer realnega sistema, ki ne temelji na protokolu RESTful, je tradicionalna zbirka domačih filmov. Za dostop do posameznega filma mora lastnik knjižnice pridobiti njegovo fizično kopijo. To povzroča precejšnjo izgubo, saj obstaja več kopij, kot se jih v danem trenutku uporablja. Tudi čas, potreben za dodajanje novih naslovov v knjižnico, na splošno ni trivialen. Streaming video je REST-ovski ekvivalent domači knjižnici: namesto da bi bila doma shranjena celotna kopija vsakega filma, se na film sklicujemo le z naslovom, vsebina pa se prenaša na zahtevo.

Svetovni splet je danes največji primer sistema RESTful. Fizične knjižnice so njegov ekvivalent, ki ni RESTful. Namesto da bi vsaki osebi ali knjižnici poslali fizično elektronsko kopijo vsakega digitalnega vira, vsakemu viru dodelimo identifikator URL »http://example.com«, do dejanske vsebine pa dostopamo prek interneta, namesto da bi lokalno kopijo pridobili z optičnega ali trdega diska.

Arhitekturo REST je mogoče uporabiti tudi v drugih kontekstih. Na primer, upoštevajte dve podjetji, ki si želita deliti več gigabajtov informacij, ki se nenehno spreminjajo. Redno pošiljanje celotne kopije njunih podatkovnih zbirk drug drugemu (tudi prek interneta) je potraten in dolgotrajen postopek. Ta način izmenjave informacij je podoben prej navedenemu primeru knjižnice. Namesto tega si lahko podjetji izmenjujeta identifikatorje svojih podatkovnih zbirk in morda vsakemu elementu dodelita svoj URL. Ko želi eno podjetje poizvedovati po podatkovni zbirki za ceno določenega predmeta, ki pripada drugemu podjetju, lahko pridobi podatke samo za ta določen inventarni element.

Glavna načela REST

• Viri in URI: Osnovna enota je vir (resource), ki ga identificira enoličen URI/URL (npr. /uporabniki/42). Vir je lahko uporabnik, naročilo, fotografija ipd.
• Predstavitve (representations): Do istega vira lahko dostopamo v različnih oblikah, npr. JSON, XML ali HTML. Odjemalec z glavo Accept pove, katero obliko želi, strežnik pa odgovori z glavo Content-Type.
• Enotni vmesnik (Uniform Interface): Standardne metode HTTP označujejo namen operacije:
  • GET za pridobivanje (brez stranskih učinkov),
  • POST za ustvarjanje podvira ali dejanje,
  • PUT za popolno zamenjavo vira,
  • PATCH za delno posodobitev,
  • DELETE za brisanje.
• Brezstanjskost (stateless): Vsaka zahteva vsebuje vse informacije za obdelavo (avtentikacija, kontekst). Strežnik med zahtevami ne hrani seje odjemalca, kar poenostavi razširljivost.
• Predpomnjenje (caching): Odzive lahko predpomnimo z Cache-Control, ETag in Last-Modified, s čimer zmanjšamo zakasnitve in obremenitev.
• Večplastnost: Med odjemalcem in strežnikom lahko obstajajo posredniki (proxyji, prehodi, CDN), ne da bi to vplivalo na semantiko.
• Koda na zahtevo (opcijsko): Strežnik lahko pošlje izvajalno kodo (npr. JavaScript), ki razširi funkcionalnost odjemalca.

Kako izgleda REST API v praksi

Primer dostopa do vira »film«:

GET /api/filmi/42 Accept: application/json  HTTP/1.1 200 OK Content-Type: application/json  {   "id": 42,   "naslov": "Primer",   "leto": 2023 } 

Ustvarjanje novega vira:

POST /api/filmi Content-Type: application/json  { "naslov": "Novi film", "leto": 2025 }  HTTP/1.1 201 Created Location: /api/filmi/43 

Idempotentnost: GET, PUT in DELETE so idempotentne (ponavljanje iste zahteve ima isti učinek); POST praviloma ni, PATCH je lahko ne-idempotenten. Statusne kode, ki jih pogosto srečamo: 200 (OK), 201 (Created), 204 (No Content), 304 (Not Modified), 400 (Bad Request), 401 (Unauthorized), 403 (Forbidden), 404 (Not Found), 409 (Conflict), 415 (Unsupported Media Type), 422 (Unprocessable Entity), 429 (Too Many Requests), 500 (Internal Server Error).

Prednosti in slabosti

• Prednosti: preprostost in jasna semantika HTTP, dobra podpora v brskalnikih in knjižnicah, učinkovito predpomnjenje, enostavno razširjanje in porazdeljenost, ločevanje odjemalca in strežnika, visoka združljivost s spletnimi standardi.
• Slabosti: brezstanjskost zahteva ponavljanje podatkov (npr. žetoni), več zaporednih klicev za kompleksne operacije (t. i. »chattiness«), transakcije prek več virov so zahtevne, hipermedija (HATEOAS) je v praksi redko dosledno uporabljena.

Primeri uporabe

• Javne API-storitve (zemljevide, vreme, plačila) za mobilne in spletne aplikacije.
• Mikrostoritve, ki med seboj komunicirajo prek HTTP.
• IoT-naprave, ki izpostavijo senzorje kot vire.
• Notranje poslovne integracije, kjer sta pomembni razširljivost in neodvisno uvajanje komponent.

Najboljše prakse za zasnovo REST API

• Konsistentni URI-ji in samostalniki v množini (npr. /uporabniki/, /naročila/); brez glagolov v poteh.
• Filtriranje, razvrščanje in paginacija prek parametrov poizvedbe (npr. ?page=2&limit=50&sort=-datum) in glave Link za povezave na naslednje/prevodne strani.
• Različice API (npr. /v1/ ali preko glave), jasno označevanje sprememb in ohranjanje združljivosti čim dlje.
• Standardizirani odzivi o napakah z jasnimi kodami in sporočili (polja code, message, details).
• Varnost: TLS (HTTPS), preverjanje pristnosti (npr. OAuth 2.0, žetoni JWT), nadzor hitrosti (rate limiting), validacija vhodov.
• Predpomnjenje in pogajanja o vsebini z ETag, If-None-Match, Accept/Content-Type.
• Idempotency-Key za varno ponavljanje zahtevkov POST pri omrežnih napakah.
• Dokumentacija in samodejno generiranje specifikacij (OpenAPI/Swagger) ter primeri uporabe.

REST in alternative

• REST vs. SOAP: SOAP uporablja strožje protokole in sheme XML, primeren je za stroge pogodbe in kompleksne transakcije; REST je lažji in bolj spletno usmerjen.
• REST vs. GraphQL: GraphQL omogoča natančno pridobivanje podatkov z eno poizvedbo, kar zmanjša »over-fetching«; REST je enostavnejši, naravno predpomnljiv in bolj skladen s HTTP semantiko.
• REST vs. gRPC: gRPC je učinkovit binarni protokol z nizko zakasnitvijo, primeren za komunikacijo med storitvami; REST je širše interoperabilen s spletnimi odjemalci.

Pogoste zmote

• »REST = JSON prek HTTP«: REST je širši niz načel; JSON je le ena izmed predstavitev.
• »RESTful URI-ji naj vsebujejo glagole«: dejanja izražajo metode HTTP, ne poti (URI).
• »Put vedno za posodobitev«: PUT zamenja celoten vir, PATCH delno posodobi; izberemo glede na semantiko.
• »Seje na strežniku so nujne«: REST predpostavlja brezstanjskost; stanje o odjemalcu nosi odjemalec (npr. žetoni).

Kdaj REST ni najboljša izbira

• Interaktivna dvosmerna komunikacija v realnem času (rabi se WebSocket ali Server-Sent Events).
• Stroge večstopenjske transakcije prek številnih virov (razmislite o drugih vzorcih ali protokolih).
• Zelo kompleksne, prilagojene poizvedbe nad grafi podatkov (primernejši je GraphQL ali namenski poizvedovalni sloj).

Vprašanja in odgovori

V: Kaj je REST (Representational State Transfer)?

V: Kako se imenujejo sistemi, ki izvajajo REST?

V: Kako računalniški sistemi komunicirajo med seboj z uporabo REST?

V: Kaj dokumentira REST?

V: Kdo je ustvaril arhitekturni slog programske opreme REST (Representational State Transfer)?

V: Kakšno vrsto komunikacije uporablja REST?

V: Kakšen je namen REST (Representational State Transfer)?

Išči po črki