Kasutaja:Kristokarp/REST arhitektuur: erinevus redaktsioonide vahel

Eemaldatud sisu Lisatud sisu
HPook (arutelu | kaastöö)
Resümee puudub
Lehekülg asendatud tekstiga 'Artikkel asub nüüd siin.'
Märgis: Asendamine
 
1. rida:
Artikkel asub nüüd [[REST|siin]].
'''REST''' ('''Representational State Transfer''')<ref name="definitsioon">{{Netiviide|URL=https://akit.cyber.ee/term/10843%20AKIT%20REST|Pealkiri=REST definitsioon|Kasutatud=30.11.2018}}</ref> on tarkvaraarhitektuuri stiil, mis seab veebirakenduse loomisel kindlad piirid. Tihti kutsutakse sellised veebirakendusi ka RESTful veebirakendusteks. Veebirakendused, mis on ehitatud REST arhitektuuril, tagavad [[internet|internetis]] rakenduste koostoimimise. RESTful rakendused lubavad teistel süsteemidel ligi pääseda ja manipuleerida enda ressursse, kasutades selleks eelnevalt kindlaks määratud ilma [[olekuta]] päringuid. Muud arhitektuurid, nagu näiteks [[SOAP]], kasutavad oma enda operatsioonide komplekte.<ref name="www">{{Netiviide|Autor=World Wide Web Consortium|URL=https://www.w3.org/TR/2004/NOTE-ws-arch-20040211/#relwwwrest|Pealkiri=Web Services Architecture|Väljaanne=|Aeg=11. veebruar 2004|Kasutatud=04.11.2018}}</ref>
 
REST arhitektuuri põhiidee seisneb selles, et tehakse erinevat tüüpi päringuid REST arhitektuuriga üles seatud erinevatele [[URI|URI-dele]], mis seejärel vastavad sobiva vastusega. Vastuse formaat seejuures ei ole kindlaks määratud ja oleneb rakenduse tüübist. Enamlevinud formaadid on [[JSON]], [[HTML]] ja [[XML]]. Rakenduselt saadud vastus sisaldab endas [[staatuse koodi]], mis ütleb, kas tehtud päring oli edukas, ja olenevalt päringust ka lisaandmeid, mida rakenduselt küsiti. Kui kasutatakse [[HTTP|HTTP-d]], mis on kõige levinum protokoll RESTful rakenduste jaoks, siis olemasolevate operatsioonde hulka kuuluvad GET, POST, PUT, DELETE ja PATCH operatsioonid, tihti tuntud ka kui [[CRUD]] operatioonid.<ref name="www"></ref>
 
Kasutades sobivaid protokolle ja standardseid operatsioone, püüavad RESTful süsteemid komponentide uuesti kasutamise ja värskendamisega saavutada suurt jõudlust, usaldusväärsust ja võimet laieneda, ilma kogu töötavat süsteemi mõjutamata.<ref name="www"></ref>
 
Termini ''representational state transfer'' defineeris ja võttis kasutusele [[Roy Fielding]] 2000. aastal oma doktoritöös.<ref name="Fielding-Ch">{{Netiviide|URL=http://www.ics.uci.edu/~fielding/pubs/dissertation/evaluation.htm|Pealkiri=Architectural Styles and the Design of Network-based Software Architectures|Autor=Roy Thomas Fielding|Väljaandja=University of California, Irvine|Aeg = 2000|Kasutatud = 30.11.2018}}</ref><ref>{{Netiviide|URL=https://groups.yahoo.com/neo/groups/rest-discuss/conversations/topics/6735|Pealkiri=Fielding discussing the definition of the REST term|Väljaandja=groups.yahoo.com|Kasutatud=08.08.2017}}</ref> Fieldingi töö seletas RESTi põhimõtteid, mida senimaani nimetati "HTTP objekti mudeliks", mis oli kasutusel aastast 1994 ja seda kasutati HTTP 1.1 ja URI standardite disainimiseks.<ref>{{Netiviide|Autor=T. Berners-Lee, R. Fielding, H. Frystyk|URL=https://tools.ietf.org/html/rfc1945|Pealkiri=RFC 1945|Väljaanne=|Aeg=Mai 1996|Kasutatud=02.12.2018}}</ref><ref>{{Netiviide|Autor=R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee|URL=https://tools.ietf.org/html/rfc2616|Pealkiri=RFC 2616|Väljaanne=|Aeg=Juuni 1999|Kasutatud=02.12.2018}}</ref><ref name="Fielding-Ch"></ref> Mõiste eesmärk on kujundada hästi kavandatud veebirakenduse käitumine: see on veebiressursside võrk (virtuaalne olek-masin), kus kasutaja edastab rakenduse kaudu, valides lingid, näiteks /user/tom ja sellised toimingud nagu GET või DELETE (seisundi muudatus), mille tulemuseks edastatakse kasutajale järgmine ressurss, mis esindab rakenduse järgmist seisundit.<ref>{{Netiviide|URL=https://www.servage.net/blog/2013/04/08/rest-principles-explained/|Pealkiri=REST principles explained|Väljaandja=Servage|Kasutatud=30.11.2018}}</ref>
 
== Ajalugu ==
[[Fail:Roy_Fielding_at_OSCON_2008.jpg|pisi|Roy Fielding esinemas OSCON-il 2008.]]
[[Roy Fielding]] määratles REST arhitektuuri oma 2000. aasta doktoritööga "Arhitektuuri stiilid ja võrgupõhiste tarkvaraspetsifikaatide projekteerimine" [[California Ülikool|California Ülikoolis]]. Ta arendas 1996.–1999. aastatel HTTP 1.1 protokolli, mis baseerus 1996. aastal loodud [[HTTP]] 1.0 peal.<ref name="Fielding-discuss">{{Netiviide|url=http://tech.groups.yahoo.com/group/rest-discuss/message/6757|Pealkiri=Fielding discusses the development of the REST style|publisher=Tech.groups.yahoo.com|Kasutatud=14.09.2014|Arhiivimisurl=https://web.archive.org/web/20091111012314/http://tech.groups.yahoo.com/group/rest-discuss/message/6757|Arhiivimisaeg=11.11.2009}}</ref> Tagasiulatuvalt REST arhitektuuri arendamisele ütles Fielding järgmist:
 
 
{| class="cquote pullquote" style="margin: auto auto 10px; border-collapse: collapse; border: none; background-color: transparent; width: auto;" role="presentation"
| style="width: 20px; vertical-align: top; border: none; color: #B2B7F2; font-size: 40px; font-family: 'Times New Roman', Times, serif; font-weight: bold; line-height: .6em; text-align: left; padding: 10px 10px;" id="48" |"
| style="vertical-align: top; border: none; padding: 4px 10px;" id="50" |HTTP standardimisprotsessi käigus kutsuti mind üles kaitsma veebi disainivalikuid. See on äärmiselt keeruline asi, mida teha protsessis, mis võtab vastu ettepanekud kõikidel teemadel, mis on kiiresti muutumas kogu tööstusharu keskmesse. Mul oli kommentaare rohkem kui 500 arendajalt, kellest paljud olid kümnete aastate suuruse kogemusega insenerid, ja ma pidin seda selgitama kõige abstraktsematest interaktiivsest suhtumistest kuni HTTP-süntaksi parimate üksikasjadega. See protsess muutis minu mudeli põhimõtteid, omadusi ja piiranguid, mida nüüd nimetatakse RESTiks.<ref name="Fielding-discuss"></ref><br />
| style="width: 20px; vertical-align: bottom; border: none; color: #B2B7F2; font-size: 40px; font-family: 'Times New Roman', Times, serif; font-weight: bold; line-height: .6em; text-align: right; padding: 10px 10px;" id="55" |"
|}
 
== Arhitektuuri omadused ==
REST arhitektuuri stiili piirangud mõjutavad järgmisi arhitektuurilisi omadusi:
 
* komponentidevaheliste interaktsioonide jõudlus, mis võib olla kasutaja tajutava jõudluse ja võrgu tõhususe domineeriv tegur;<ref name="Fielding-Ch"></ref>
* skaleeruvus, mis võimaldab toetada suurt hulka komponente ja nendevahelisi interaktsioone;
*ühtse liidese lihtsus;
* komponentide muutmine uute vajaduste rahuldamiseks, isegi kui rakendus töötab;
* teenindusagentide ja komponentide vahelise kommunikatsiooni läbipaistvus;
* komponentide teisaldatavus programmi koodi ja andmete abil;
* süsteemi stabiilsus pistikühendustes, komponentides või andmetes esinevate tõrgete korral.
 
Roy Fielding kirjeldab RESTi skaleeruvust järgmiselt:<br />
{| class="cquote pullquote" style="margin: auto auto 10px; border-collapse: collapse; border: none; background-color: transparent; width: auto;" role="presentation"
| style="width: 20px; vertical-align: top; border: none; color: #B2B7F2; font-size: 40px; font-family: 'Times New Roman', Times, serif; font-weight: bold; line-height: .6em; text-align: left; padding: 10px 10px;" id="66" |"
| style="vertical-align: top; border: none; padding: 4px 10px;" id="68" |RESTi klient-serveri lahutamine lihtsustab komponentide rakendamist, vähendab pistikühenduse semantika keerukust, parandab jõudluse häälestamise efektiivsust ja suurendab täielike serverikomponentide skaleerumisvõimet. Kihtsüsteemi piirangud võimaldavad vahendajaid – puhverservereid, lüüse ja tulemüüre kasutada mitmesugustes kommunikatsioonipunktides, muutmata komponentide vahelisi liideseid, võimaldades seega neil abistada suhtlemist tõlkimisel või suurendada jõudlust kasutades jagatud puhvrit. REST võimaldab sõnumite vahepealset töötlemist: suhtlus päringute vahel on ilma olekuta, semantika ja teabe vahetamiseks kasutatakse standardseid meetodeid ja meediumitüüpe ning vastused lubavad puhvri kasutust.<ref name="Fielding-Ch"></ref><br />
| style="width: 20px; vertical-align: bottom; border: none; color: #B2B7F2; font-size: 40px; font-family: 'Times New Roman', Times, serif; font-weight: bold; line-height: .6em; text-align: right; padding: 10px 10px;" id="77" |"
|}
 
== URLi ja sobivate HTTP meetodite kasutamine ==
Järgnev tabel demonstreerib, kuidas [[HTTP]] meetodeid tavaliselt REST API-des kasutatakse:
{| class="wikitable" style="margin-bottom: 82px;"
|+HTTP meetodid
!Uniform Resource Locator (URL)
!GET
!PUT
!PATCH
!POST
!DELETE
|-
!Kollektsioon<br /><code><nowiki>https://api.example.com/resources/</nowiki></code>
|'''Tagastatakse''' list kollektsiooni elementide URI-dest ja vahel ka muust nendega seonduvast infost.
|'''Asendatakse''' kogu kollektsiooni teise kollektsiooniga.
|Üldiselt seda ei kasutata.
|'''Luuakse''' uus kirje kollektsiooni. Uue kirje on URI on loodud automaatselt ja on tavaliselt ka vastuses tagastatud.
|'''Kustutatakse''' kogu kollektsioon.
|-
!Element<br /> <code><nowiki>https://api.example.com/resources/item17</nowiki></code>
|'''Tagastatakse''' kollektsiooni elemendi andmed sobivad meediatüübis.
|'''Asendatakse''' olemasolev element või luuakse selle puudumisel uus element.
|'''Uuendatakse''' olemasolevat elementi uute andmetega.
|Üldiselt seda ei kasutata, kuid kasutamisel on selle eesmärk muuta element omakorda kollektsiooniks.<ref>{{Netiviide|Autor=Jeremy H|URL=http://thereisnorightway.blogspot.com/2012/05/api-example-using-rest.html|Pealkiri=API Example Using REST|Väljaanne=|Aeg=16. mai 2012|Kasutatud=04.11.2018}}</ref>
|'''Kustutatakse''' element kollektsioonist.
|}
 
== Viited ==
{{Reflist|2}}