REST ( edustustilan siirto ) on ohjelmistoarkkitehtuurityyli, joka määrittelee joukon rajoituksia, joita käytetään verkkopalvelujen luomiseen . REST-arkkitehtuurityyppiset verkkopalvelut, jotka tunnetaan myös nimellä RESTful- verkkopalvelut , luovat Internetissä olevien tietokoneiden välisen yhteentoimivuuden . REST-verkkopalvelut sallivat pyytävien järjestelmien manipuloida verkkoresursseja tekstimuotoisten esitystensä kautta yhtenäisten, ennalta määriteltyjen valtiottomien operaatioiden avulla . Muun tyyppiset verkkopalvelut, kuten SOAP- verkkopalvelut paljastaa omat mielivaltaisten toimintojensa joukot.
Web-resurssit määriteltiin ensin Internetissä asiakirjoina tai tiedostoina, jotka tunnistettiin niiden URL-osoitteen perusteella . Nykyään niillä on kuitenkin paljon yleisempi ja abstraktin määritelmä, joka sisältää kaiken tai kokonaisuuden, joka voidaan tunnistaa, nimetä, käsitellä tai jollain tavalla hallita verkossa. REST-verkkopalvelussa resurssin URI : lle tehdyt pyynnöt tuottavat vastauksen, jonka runko on muotoiltu HTML- , XML- , JSON- tai muussa muodossa. Vastaus voi vahvistaa, että tallennettu resurssi on vioittunut, ja se voi tarjota hyperlinkkejä muihin aiheeseen liittyviin resursseihin tai resurssien kokoelmaan. Kun käytetään HTTP- protokollaa , kuten usein tapahtuu, käytettävissä olevat HTTP-menetelmät ovat GET, HEAD, POST, PUT, PATCH, DELETE, CONNECT, OPTIONS ja TRACE.
Käyttämällä valtiottomia protokollia ja vakiotoimintoja REST-järjestelmät pyrkivät reagoivuuteen, luotettavuuteen ja skaalautuvuuteen uudelleenkäyttämällä komponentteja, joita voidaan hallita ja päivittää vaikuttamatta koko järjestelmään edes pitkiä aikoja.
Termi rest määriteltiin ensimmäisen kerran vuonna 2000 Roy Fielding luvussa 5 hänen väitöskirjaansa . Fieldingin opinnäytetyössä selitettiin REST: n periaatteet, jotka tunnettiin aiemmin nimellä "HTTP-objektimalli" vuodesta 1994 lähtien ja joita käytettiin HTTP 1.1- ja URI-standardien kehittämisessä. Termin on tarkoitus viitata hyvin suunnitellun verkkosovelluksen käyttäytymiseen: se on resurssiverkosto (virtuaalinen tilakone), jossa käyttäjä kehittyy valitsemalla resurssitunnisteita, kuten http: //www.example .com / articles / 21 ja resurssioperaatiot, kuten GET tai POST (sovellustilan siirtymät), jotka siirtävät seuraavan resurssin (uuden sovellustilan) esityksen käytettävälle käyttäjälle.
Roy Fielding määritelty REST vuonna 2000 väitöskirjassaan arkkitehtuurityylien ja suunnittelu Verkko-pohjainen Ohjelmistoarkkitehtuurit on University of California at Irvine . Siellä hän kehitti REST-tyylisen arkkitehtuurin HTTP 1.1 -protokollan rinnalla vuosina 1996-1999, perustuen olemassa olevaan HTTP 1.0 -malliin vuodesta 1996.
Retrospektiivisessä tarkastelussa REST: n kehitystä Fielding sanoi:
Koko HTTP-standardointiprosessin ajan minua kehotettiin puolustamaan verkon suunnitteluvaihtoehtoja. Se on erittäin vaikeaa tehdä prosessissa, joka hyväksyy kenenkään ehdotukset aiheesta, josta on nopeasti tulossa koko teollisuuden keskus. Minulla oli kommentteja yli 500 kehittäjältä, joista monet olivat arvostettuja insinöörejä, joilla oli vuosikymmenien kokemus, ja jouduin selittämään kaiken abstrakteimmista käsityksistä web-vuorovaikutuksesta aina HTTP-syntaksin hienoimpiin yksityiskohtiin. Tämä prosessi hiotti mallini ydinjoukkoihin periaatteita, ominaisuuksia ja rajoituksia, joita nyt kutsutaan RESTiksi.
"HTTP-standardointiprosessin aikana minua kehotettiin puolustamaan verkon arkkitehtonisia valintoja. Se on äärimmäisen monimutkainen tehtävä, koska menettely hyväksyy kenenkään huomautukset aiheesta, josta nopeasti tuli koko alan painopiste. Sain palautetta yli 500 kehittäjältä, joista monet olivat tunnettuja insinöörejä, joilla oli vuosikymmenien kokemus, ja jouduin selittämään kaiken abstrakteimmista käsityksistä verkkoyhteisöistä web-syntaksin yksityiskohtiin. HTTP. Tämä menettely pienensi mallini perusperiaatteiksi, ominaisuuksiksi ja rajoituksiksi, joita nykyään kutsutaan RESTiksi. "
Kuusi arkkitehtonista rajoitusta määrittelee REST-järjestelmän. Nämä rajoitukset rajoittavat palvelimen tapaa käsitellä ja vastata asiakkaiden pyyntöihin siten, että toimimalla näiden rajoitusten puitteissa järjestelmä saa halutut ei-toiminnalliset ominaisuudet, kuten suorituskyvyn, skaalautuvuuden, yksinkertaisuuden, skaalautuvuuden jne. Näkyvyyden, siirrettävyyden ja luotettavuuden. Järjestelmän, joka rikkoo yhtä näistä rajoituksista, ei voida katsoa noudattavan REST-arkkitehtuuria.
Vastuut on jaettu asiakkaan ja palvelimen välillä. Käyttöliittymän irrottaminen datamuistista parantaa käyttöliittymän siirrettävyyttä useilla alustoilla. Järjestelmän skaalautuvuutta parantaa myös palvelinkomponenttien yksinkertaistaminen. Mutta ehkä vieläkin tärkeämpi verkolle, erottaminen antaa komponenttien kehittyä itsenäisesti, mikä tukee useita organisaation alueita, joita tarvitaan Internetin laajentamiseen.
Asiakas - palvelin viestintä tapahtuu pitämättä tila viestinnän istunnon palvelimessa kahden peräkkäisen pyyntöjä. Asiakas pitää istunnon tilan ja välittää sen jokaisen uuden pyynnön yhteydessä. Asiakkaan pyynnöt sisältävät siis kaikki tarvittavat tiedot, jotta palvelin voi vastata niihin. Komponenttien välisen vuorovaikutuksen näkyvyys on parantunut, koska pyynnöt ovat täydelliset. Epäonnistumisen suvaitsevaisuus on myös suurempi. Lisäksi se, että asiakkaan ja palvelimen välillä ei tarvitse olla pysyvää yhteyttä, antaa palvelimen vastata muiden asiakkaiden muihin pyyntöihin kyllästämättä kaikkia viestintäportteja, mikä parantaa suorituskykyä.
Tavanomainen poikkeus tähän valtiottomaan tilaan on kuitenkin asiakkaan todennuksen hallinta, jotta jälkimmäisen ei tarvitse palauttaa näitä tietoja kuhunkin pyyntöönsä.
Asiakkaat ja välipalvelimet voivat tallentaa vastaukset välimuistiin. Siksi vastaukset tulisi implisiittisesti tai nimenomaisesti määritellä välimuistiin tallennettaviksi tai ei, jotta estetään asiakkaita hakemasta vanhentuneita tai sopimattomia tietoja vastauksena myöhempiin pyyntöihin. Hyvin hoidettu välimuisti eliminoi osittain tai kokonaan asiakkaan ja palvelimen välisen vuorovaikutuksen, mikä parantaa järjestelmän skaalautuvuutta ja suorituskykyä edelleen.
Asiakas ei yleensä pysty selvittämään, onko se kytketty suoraan loppupalvelimeen vai välipalvelimeen. Välipalvelimet voivat parantaa järjestelmän skaalautuvuutta toteuttamalla kuormituksen tasapainottamisen ja jaetun välimuistin. Ne voivat myös vahvistaa turvallisuuspolitiikkaa.
Palvelimet voivat tilapäisesti laajentaa tai muokata asiakkaan toimintoja lataamalla siihen suoritettavan koodin. Esimerkiksi Java-sovelmilla tai JavaScript- skripteillä . Tämä auttaa asiakkaita yksinkertaistamaan vähentämällä oletusarvoisesti tarvittavien ominaisuuksien määrää ja parantamaan järjestelmän skaalautuvuutta. Toisaalta se vähentää myös resurssiorganisaation näkyvyyttä. Siksi se muodostaa valinnaisen rajoituksen REST-arkkitehtuurille.
Yhdenmukainen rajapinnan rajoitus on olennainen minkä tahansa REST-järjestelmän suunnittelussa. Se yksinkertaistaa ja irrottaa arkkitehtuurin, jolloin kukin osa voi kehittyä itsenäisesti. Yhdenmukaisen rajapinnan neljä rajoitusta ovat seuraavat.
Resurssien tunnistaminen kyselyissä Jokainen resurssi tunnistetaan pyynnöissä, esimerkiksi URI : llä verkkopohjaisten REST-järjestelmien tapauksessa. Resurssit itsessään ovat käsitteellisesti erillisiä asiakkaalle palautettavista esityksistä. Esimerkiksi palvelin voi lähettää tietoja tietokannastaan HTML- , XML- tai JSON-muodossa , jotka ovat erilaisia esityksiä resurssin sisäisestä edustuksesta. Resurssien käsittely edustuksilla Jokainen resurssin esitys antaa asiakkaalle riittävästi tietoa resurssin muokkaamiseen tai poistamiseen. Itsekuvaavat viestit Jokainen viesti sisältää tarpeeksi tietoa sen tulkitsemiseksi. Esimerkiksi tulkkia, jota kutsutaan, voidaan kuvata tietyntyyppisellä medialla . Hypermedia sovellustilan moottorina ( HATEOAS ) Saatuaan sovelluksen alkuperäisen URI: n - samalla tavalla kuin ihmiset pääsevät verkkosivuston kotisivulle - asiakkaan tulee pystyä käyttämään dynaamisesti palvelimen tarjoamia hyperlinkkejä muiden mahdollisten toimintojen ja resurssien löytämiseen selaamisen jatkamiseksi. Asiakkaan ei tarvitse koodata näitä tietoja sovelluksen rakenteesta tai dynamiikasta.RESTin arkkitehtoniset rajoitteet antavat niitä kunnioittaville järjestelmille seuraavat arkkitehtoniset ominaisuudet:
REST: n asiakas - palvelin-ongelmien erottaminen yksinkertaistaa komponenttien toteutusta, vähentää liittimien semantiikan monimutkaisuutta, parantaa suorituskyvyn virityksen tehokkuutta ja lisää puhtaiden palvelinkomponenttien skaalautuvuutta. Kerroksiset järjestelmän rajoitteet mahdollistavat välittäjien - välityspalvelimet, yhdyskäytävät ja palomuurit - käyttöönoton viestinnän eri kohdissa muuttamatta komponenttien välisiä rajapintoja, jolloin ne voivat auttaa viestinnän kääntämisessä tai parantamaan suorituskykyä laajamittaisen jaetun välimuistin avulla. REST mahdollistaa välitön prosessoinnin rajoittamalla viestejä olemaan itse kuvaava: pyyntöjen välinen vuorovaikutus on tilaton, semantiikan osoittamiseen ja tiedonvaihtoon käytetään standardimenetelmiä ja mediatyyppejä, ja vastaukset osoittavat nimenomaisesti välimuistin.
" Asiakas - palvelin- huolenaiheiden erottaminen yksinkertaistaa komponenttien toteutusta, vähentää liittimien semantiikan monimutkaisuutta, parantaa suorituskyvyn virityksen tehokkuutta ja lisää puhtaiden palvelinkomponenttien skaalautuvuutta. Kerroksinen arkkitehtuurirajoitus mahdollistaa välittäjien - välityspalvelimet, yhdyskäytävät ja palomuurit - käyttöönoton eri tasoilla viestinnässä muuttamatta komponenttien välisiä rajapintoja, jolloin ne voivat puuttua viestinnän käännökseen tai parantaa suorituskykyä laajamittaisen välimuistin avulla. järjestelmät. REST sallii välitön käsittelyn pakottamalla itse kuvaavat viestit: pyyntöjen välinen vuorovaikutus on tilaton, semantiikan osoittamiseen ja tiedonvaihtoon käytetään standardimenetelmiä ja mediatyyppejä, ja vastaukset osoittavat nimenomaisesti välimuistin mahdollisuuden. "
API REST-pohjainen HTTP määritellään:
Seuraava taulukko osoittaa, kuinka HTTP-menetelmiä käytetään tyypillisesti REST-sovellusliittymässä:
URI | SAADA | LÄHETTÄÄ | LAITTAA | PATCH | POISTAA |
---|---|---|---|---|---|
Resurssien kerääminen, kuten http://api.exemple.com/collection/ | Hakee keräysresurssin resurssijäsenten URI: t vastausrungossa. | Luo jäsenresurssin kokoelmaresurssiin pyyntörungon ohjeiden avulla. Luodun jäsenresurssin URI määritetään automaattisesti ja palautetaan vastauksen Sijainti- otsikkokenttään . | Korvaa kaikki kokoelma-resurssin jäsenresurssien esitykset pyynnön rungossa olevalla esityksellä tai luo kokoelmaresurssin, jos sitä ei ole. | Päivittää kaikki kokoelma-resurssin jäsenresurssien esitykset pyynnön rungossa olevien ohjeiden avulla tai valinnaisesti luo kokoelmaresurssin, jos sitä ei ole. | Poistaa kaikki jäsenresurssien esitykset kokoelmaresursseista. |
Jäsenresurssi, kuten http://api.exemple.com/collection/item3 | Hakee esityksen jäsenresurssista vastausrungossa. | Luo jäsenresurssin jäsenresurssiin pyyntörungon ohjeiden avulla. Luodun jäsenresurssin URI määritetään ja palautetaan automaattisesti vastauksen Sijainti- otsikkokenttään . | Korvaa kaikki jäsenresurssin edustukset tai luo jäsenresurssin, jos sitä ei ole, pyynnön rungossa olevalla esityksellä. | Päivittää kaikki jäsenresurssin esitykset tai valinnaisesti luo jäsenresurssin, jos sitä ei ole, käyttämällä pyyntörungon ohjeita. | Poistaa kaikki jäsenresurssin esitykset. |
GET-menetelmä on turvallinen, toisin sanoen sen soveltaminen resurssiin ei johda resurssin tilan muutokseen (vain luku -semantiikka). GET-, PUT- ja DELETE-menetelmät ovat idempotentteja , toisin sanoen niiden soveltaminen useaan kertaan resurssiin johtaa samaan muutokseen resurssin tilassa kuin soveltamalla niitä kerran, vaikka vastaus voi olla erilainen. GET- ja POST-menetelmät ovat välimuistissa , eli vastausten tallentaminen näihin pyyntöihin tulevaa uudelleenkäyttöä varten on sallittua.
Toisin kuin SOAP- suuntautuneet verkkopalvelut , REST-sovellusliittymille ei ole virallista standardia, koska REST on arkkitehtuuri ja SOAP on protokolla. REST ei ole itsessään standardi, mutta tätä arkkitehtuuria noudattavat toteutukset käyttävät standardeja, kuten HTTP , URI , JSON ja XML .