LEVÄTÄ

Kokeneet kirjoittajat eivät ole vielä tarkistaneet sivun nykyistä versiota, ja se voi poiketa merkittävästi 4.5.2022 tarkistetusta versiosta . tarkastukset vaativat 5 muokkausta .

REST ( englanniksi . Representational  State Transfer - "edustavan tilan siirto  " tai "itsekuvaavan "tilan siirto") on arkkitehtoninen vuorovaikutustyyli hajautetun sovelluksen komponenttien välillä verkossa . Toisin sanoen REST on joukko sääntöjä, joilla ohjelmoija järjestää palvelinsovelluksen koodauksen niin, että kaikki järjestelmät voivat helposti vaihtaa tietoja ja sovellus voidaan skaalata. [1] REST on johdonmukainen joukko rajoituksia, jotka on otettava huomioon suunniteltaessa hajautettua hypermediajärjestelmää . Tietyissä tapauksissa ( verkkokaupat , hakukoneet , muut tietopohjaiset järjestelmät) tämä johtaa parempaan suorituskykyyn ja yksinkertaistettuun arkkitehtuuriin. Laajassa merkityksessä[ selventää ] RESTin komponentit ovat vuorovaikutuksessa samalla tavalla kuin asiakkaat ja palvelimet ovat vuorovaikutuksessa World Wide Webissä . REST on vaihtoehto RPC :lle [2] .

Internetissä etäproseduurikutsu voi olla normaali HTTP - pyyntö (yleensä GET tai POST ; tällaista pyyntöä kutsutaan "REST-pyynnöksi" ) , ja vaaditut tiedot välitetään pyyntöparametreina [3] [4] .

Verkkopalveluissa, jotka on rakennettu RESTiä ajatellen (eli jotka eivät riko sen asettamia rajoituksia), käytetään termiä " RESTful ".

Toisin kuin SOAP -pohjaiset verkkopalvelut (verkkopalvelut), RESTful-verkkosovellusliittymälle ei ole "virallista" standardia. Asia on siinä, että REST on arkkitehtoninen tyyli , kun taas SOAP on protokolla. Vaikka REST ei ole sinänsä standardi, useimmat RESTful-toteutukset käyttävät standardeja, kuten HTTP , URL , JSON ja harvemmin XML .

Termin historia

Vaikka tämä käsite on World Wide Webin perusta , termin "REST" otti käyttöön Roy Fielding , yksi " HTTP "-protokollan luojista, vasta vuonna 2000 [4] . Väitöskirjassaan "Architectural Styles and the Design of Network-based Software Architectures" [5] Kalifornian yliopistossa Irvinessä [3] hän tarjosi teoreettisen viitekehyksen asiakkaiden ja palvelimien vuorovaikutukselle World Webissä . kutsumalla sitä "edustustilasiirroksi" (" Edustustilan siirto » ). Fielding kuvasi hajautetun sovelluksen rakentamisen konseptia, jossa jokainen asiakkaalta palvelimelle lähettämä pyyntö (REST-pyyntö) sisältää kattavat tiedot halutusta palvelimen vastauksesta (haluttu edustajatila), eikä palvelimen tarvitse tallentaa tilatietoja. asiakkaan ("asiakasistunto").

"REST"-tyyli kehittyi rinnakkain vuosina 1996-1999 kehitetyn " HTTP 1.1 ":n kanssa perustuen olemassa olevaan " HTTP 1.0" -malliin, joka kehitettiin vuonna 1996 [6] .

REST-arkkitehtuurin ominaisuudet

REST-järjestelmien rajoituksista riippuvat arkkitehtoniset ominaisuudet:

Roy Fielding, yksi HTTP-protokollaspesifikaatioiden päätekijöistä, kuvaa REST-arkkitehtuurin vaikutusta skaalautumiseen seuraavasti:

REST-arkkitehtuurivaatimukset

Kentän [3] [7] mukaan hajautettujen REST-sovellusten rakentamiseen on kuusi pakollista rajoitusta .

Nämä rajoitukset ovat pakollisia REST-järjestelmille [8] [9] . Asetetut rajoitukset määrittävät palvelimen toiminnan sen suhteen, miten se voi käsitellä asiakkaiden pyyntöjä ja vastata niihin. Näiden rajoitusten puitteissa toimimalla järjestelmä saa toivottuja ominaisuuksia, kuten suorituskykyä, skaalautuvuutta, yksinkertaisuutta, mukautuvuutta, siirrettävyyttä, jäljitettävyyttä ja luotettavuutta.

Jos palvelusovellus rikkoo jotakin näistä rajoittavista ehdoista, järjestelmää ei voida pitää REST-järjestelmänä [3] .

Pakolliset ehdot-rajoitukset ovat:

1. Asiakas-palvelin malli

Ensimmäinen hybridimallia koskeva rajoitus on tuoda arkkitehtuuri asiakas-palvelin-malliin. Tarpeiden rajaaminen on tämän määrätyn rajoituksen taustalla. Asiakasrajapinnan tarpeiden erottaminen dataa tallentavan palvelimen tarpeista lisää asiakasliittymäkoodin siirrettävyyttä muille alustoille , kun taas taustan yksinkertaistaminen parantaa skaalautuvuutta . Ehkä suurin vaikutus World Wide Webiin on itse rajaus, joka mahdollistaa erillisten osien kehittymisen toisistaan ​​riippumatta, mikä tukee Internetin kehitystarpeita eri organisaatioilta. [3]

2. Tilan puute

Asiakkaan ja palvelimen välinen vuorovaikutusprotokolla vaatii seuraavan ehdon: asiakaspyyntöjen välisenä aikana palvelimelle ei tallenneta tietoja asiakkaan tilasta ( Stateless Protocol tai "stateleless protocol"). Kaikki asiakkaalta tulevat pyynnöt tulee muotoilla siten, että palvelin saa kaikki tarvittavat tiedot pyynnön suorittamiseen. Istuntotila tallennetaan asiakaspuolelle [3] . Palvelin voi välittää istunnon tilatiedot jollekin muulle palvelulle (esimerkiksi tietokantapalvelulle) ylläpitääkseen vakaata tilaa esimerkiksi autentikoinnin muodostamisen ajan. Asiakas aloittaa pyyntöjen lähettämisen, kun se on valmis (välttämätön) siirtymään uuteen tilaan.

Asiakaspyyntöjen käsittelyn aikana asiakkaan katsotaan olevan siirtymätilassa . Jokaista yksittäistä sovelluksen tilaa edustavat linkit, jotka voidaan kutsua seuraavan kerran, kun asiakas osuu.

3. Välimuistiin tallentaminen

Kuten World Wide Webissä , asiakkaat sekä välipalvelimet voivat tallentaa palvelinvastaukset välimuistiin . Palvelimen vastaukset puolestaan ​​​​on nimenomaisesti tai epäsuorasti merkitty välimuistiin tai ei-välimuistiin, jotta asiakkaat eivät saa vanhentuneita tai virheellisiä tietoja vastauksena myöhempiin pyyntöihin. Välimuistin oikea käyttö voi osittain tai kokonaan eliminoida jotkin asiakkaan ja palvelimen väliset vuorovaikutukset, mikä lisää entisestään järjestelmän suorituskykyä ja skaalautuvuutta.

4. Käyttöliittymän yhtenäisyys

Yhtenäinen käyttöliittymä on perusedellytys REST-palveluille [3] . Yhtenäiset rajapinnat mahdollistavat jokaisen palvelun kehittymisen itsenäisesti.

Yhtenäisiä liitäntöjä koskevat seuraavat neljä rajoitusta [10] [11] :

Resurssien tunnistus
Kaikki resurssit tunnistetaan pyynnöissä, esimerkiksi Internet-järjestelmien URI -tunnisteilla. Resurssit ovat käsitteellisesti erillään asiakkaille palautetuista näkymistä. Palvelin voi esimerkiksi lähettää tietoja tietokannasta HTML- , XML- tai JSON - muodossa , joista kumpikaan ei ole palvelinpuolen tallennustyyppi.

Resurssien käsittely esityksen kautta
Jos asiakas tallentaa resurssin esityksen, mukaan lukien metatiedot, sillä on tarpeeksi tietoa resurssin muokkaamiseen tai poistamiseen.

"Itsekuvaavat" viestit
Jokainen viesti sisältää tarpeeksi tietoa sen käsittelyn ymmärtämiseksi. Esimerkiksi tiedon poimimiseen tarvittava sanomankäsittelijä (parser) voidaan määrittää MIME-tyyppien luettelossa [3] .

Hypermedia sovelluksen tilan muuttamisen keinona ( HATEOAS )
Asiakkaat muuttavat järjestelmän tilaa vain toimilla, jotka on dynaamisesti määritelty palvelimen hypermediassa (esim. hyperlinkit hypertekstissä ) . Lukuun ottamatta yksinkertaisia ​​sovellusten sisääntulokohtia, asiakas ei voi olettaa, että jokin toiminto on käytettävissä jollakin resurssilla, ellei sitä ole informoitu aiemmissa pyynnöissä palvelimelle. Resurssien välisten linkkien tarjoamiseen ei ole universaalia muotoa, Web Linking ( RFC 5988 -> RFC 8288 ) ja JSON Hypermedia API Language Arkistoitu 27. kesäkuuta 2014 Wayback Machinessa ovat kaksi suosittua muotoa linkkien tarjoamiseen REST HYPERMEDIA -palveluissa.

5. Tasot

Asiakas ei yleensä pysty tarkasti määrittämään, kommunikoiko se suoraan palvelimen vai välisolmun kanssa verkkojen hierarkkisesta rakenteesta johtuen (mikä tarkoittaa, että tällainen rakenne muodostaa kerroksia ). Välipalvelimien käyttö voi lisätä skaalautuvuutta kuormituksen tasapainottamisen ja hajautetun välimuistin avulla . Välisolmuihin voidaan myös soveltaa tietoturvapolitiikkaa tietojen luottamuksellisuuden varmistamiseksi [12] .

6. Code on demand (valinnainen rajoitus)

REST voi mahdollistaa asiakastoimintojen laajentamisen lataamalla koodia palvelimelta sovelmien tai komentosarjojen muodossa . Fielding väittää, että lisärajoite mahdollistaa sellaisen arkkitehtuurin suunnittelun, joka tukee haluttua toiminnallisuutta yleisesti, mutta ehkä joissakin yhteyksissä poikkeuksin.

Edut

Roy Fielding huomautti, että sovelluksia, jotka eivät täytä yllä olevia ehtoja, ei voida kutsua REST-sovelluksiksi. Jos kaikki ehdot täyttyvät, hänen mielestään hakemus saa seuraavat edut [3] [7] :

Muistiinpanot

  1. ↑ Mikä on REST API  (venäläinen)  ? . Haettu 11. elokuuta 2021. Arkistoitu alkuperäisestä 11. elokuuta 2021.
  2. ↑ Mashnin Timur Sergeevich. Java Platform Web Services -tekniikka. - BHV-Petersburg, 2012. - S. 115. - 560 s. — ISBN 978-5-9775-0778-3 .
  3. ↑ 1 2 3 4 5 6 7 8 9 10 Roy Fieldingin väitöskirjan luku 5 "Representational State Transfer (REST)" Arkistoitu 13. toukokuuta 2021 Wayback Machinessa
  4. ↑ 1 2 REST-termin määritelmää käsittelevä kenttä . tech.groups.yahoo.com. Haettu 28. marraskuuta 2013. Arkistoitu alkuperäisestä 22. lokakuuta 2010.
  5. ↑ Fieldingin väitöskirja: LUKU 5: Representational State Transfer (REST) ​​. www.ics.uci.edu. Haettu 1. joulukuuta 2015. Arkistoitu alkuperäisestä 13. toukokuuta 2021.
  6. ↑ rest-discuss : Viesti: Re: [rest-discuss RFC for REST?] (11.11.2009). Haettu 1. joulukuuta 2015. Arkistoitu alkuperäisestä 11. marraskuuta 2009.
  7. ↑ 1 2 Thomas Erl, Benjamin Carlyle, Cesare Pautasso, Raj Balasubramanian. 5.1 // SOA ja REST. - Prentice Hall, 2013. - ISBN 978-0-13-701251-0 .
  8. ↑ Thomas Erl, Benjamin Carlyle, Cesare Pautasso, Raj Balasubramanian. 5.1 // SOA ja REST  (neopr.) / Thomas Erl. - Prentice Hall , 2013. - ISBN 978-0-13-701251-0 .
  9. ↑ Richardson, Leonard & Ruby, Sam (2007), RESTful Web service , O'Reilly Media, ISBN 978-0-596-52926-0 , < https://books.google.com/books?id=XUaErakHsoAC > . Haettu 18. tammikuuta 2011. Arkistoitu 19. helmikuuta 2012 Wayback Machinessa 
  10. ↑ Wilde, Pautasso, 2011 , REST Definition.
  11. ↑ N. L. Podkolodny, A. V. Semenychev, D. A. Rasskazov, V. G. Borovsky, E. A. Ananko, E. V. Ignatieva, N. N. Podkolodnaya, O. A. Podkolodnaya, N A. Kolchanov Distributed system of RESTiceful-web. network geneconconstruction and analysis Vavilov Journal of Genetics and Breeding, osa 16, N 4/1, 2012
  12. ↑ Hartley Brody. Kuinka HTTPS suojaa yhteydet: mitä jokaisen verkkokehittäjän tulee  tietää . Arkistoitu alkuperäisestä 24. joulukuuta 2015.

Kirjallisuus

Linkit

  Siirry Wikidata-kohteeseen  Bibliografisissa luetteloissa