RESTEN

Den aktuella versionen av sidan har ännu inte granskats av erfarna bidragsgivare och kan skilja sig väsentligt från versionen som granskades den 4 maj 2022; kontroller kräver 5 redigeringar .

REST (från engelska . Representational  State Transfer - " överföring  av en representativ stat" eller "överföring av en" självbeskrivande "stat") är en arkitektonisk stil av interaktion mellan komponenter i en distribuerad applikation i ett nätverk . REST är med andra ord en uppsättning regler för hur en programmerare organiserar kodningen av en serverapplikation så att alla system enkelt kan utbyta data och applikationen kan skalas. [1] REST är en konsekvent uppsättning begränsningar att ta hänsyn till när man designar ett distribuerat hypermediasystem . I vissa fall ( nätbutiker ,sökmotorer , andra datadrivna system) vilket resulterar i förbättrad prestanda och förenklad arkitektur. I vidare mening[ förtydliga ] Komponenter i REST interagerar ungefär som klienter och servrar interagerar på World Wide Web . REST är ett alternativ till RPC [2] .

På Internet kan ett fjärrproceduranrop vara en normal HTTP - begäran (vanligtvis GET eller POST ; en sådan begäran kallas en "REST-begäran" ), och den nödvändiga informationen skickas som begäranparametrar [3] [4] .

För webbtjänster som byggts med REST i åtanke (det vill säga att de inte bryter mot begränsningarna som den ålägger), används termen " RESTful ".

Till skillnad från webbtjänster (webbtjänster) baserade på SOAP finns det ingen "officiell" standard för RESTful webb-API. Poängen är att REST är en arkitektonisk stil , medan SOAP är ett protokoll. Även om REST inte är en standard i sig använder de flesta RESTful-implementeringar standarder som HTTP , URL , JSON och, mindre vanligt, XML .

Termens historia

Även om detta koncept ligger i själva grunden för World Wide Web , introducerades termen "REST" av Roy Fielding , en av skaparna av " HTTP "-protokollet, först år 2000 [4] . I sin avhandling "Architectural Styles and the Design of Network-based Software Architectures" [5] vid University of California, Irvine [3] tillhandahöll han ett teoretiskt ramverk för hur klienter och servrar interagerar på världswebben och abstraherar det och kallar det "representativ statsöverföring" ("Representational state transfer " ). Fielding beskrev konceptet med att bygga en distribuerad applikation, där varje begäran (REST-begäran) från klienten till servern innehåller omfattande information om det önskade serversvaret (önskat representativt tillstånd), och servern behöver inte spara information om tillståndet. av klienten ("klientsession").

"REST"-stilen utvecklades parallellt med " HTTP 1.1 " som utvecklades 1996-1999 och bygger på den befintliga " HTTP 1.0"-designen som utvecklades 1996 [6] .

Egenskaper för REST-arkitekturen

Arkitektoniska egenskaper som är beroende av restriktionerna för REST-system:

Roy Fielding, en av huvudförfattarna till HTTP-protokollspecifikationen, beskriver effekten av REST-arkitekturen på skalbarheten enligt följande:

REST-arkitekturkrav

Det finns sex obligatoriska begränsningar för att bygga distribuerade REST-applikationer enligt Fielding [3] [7] .

Dessa begränsningar är obligatoriska för REST-system [8] [9] . De begränsningar som införs avgör hur servern fungerar när det gäller hur den kan behandla och svara på klientförfrågningar. Genom att arbeta inom dessa begränsningar får systemet önskvärda egenskaper såsom prestanda, skalbarhet, enkelhet, anpassningsförmåga, portabilitet, spårbarhet och tillförlitlighet.

Om tjänsteapplikationen bryter mot något av dessa restriktiva villkor kan systemet inte betraktas som ett REST-system [3] .

Obligatoriska villkor-begränsningar är:

1. Klient-servermodell

Den första begränsningen som gäller för hybridmodellen är att föra arkitekturen till klient-servermodellen. Behovsavgränsning är den princip som ligger till grund för denna pålagda begränsning. Att separera behoven hos klientgränssnittet från behoven hos servern som lagrar data ökar portabiliteten för klientgränssnittskoden till andra plattformar, samtidigt som en förenkling av back-end förbättrar skalbarheten. Den kanske största inverkan på World Wide Web är själva avgränsningen, som tillåter separata delar att utvecklas oberoende av varandra, vilket stödjer utvecklingsbehoven för Internet från olika organisationer. [3]

2. Brist på tillstånd

Interaktionsprotokollet mellan klienten och servern kräver följande villkor: under perioden mellan klientbegäranden lagras ingen information om klientens tillstånd på servern ( Stateless protocol eller "stateless protocol"). Alla förfrågningar från klienten måste utformas på ett sådant sätt att servern får all nödvändig information för att slutföra begäran. Sessionstillståndet sparas på klientsidan [3] . Sessionstillståndsinformationen kan skickas av servern till någon annan tjänst (till exempel till en databastjänst) för att upprätthålla ett stabilt tillstånd, till exempel under perioden för upprättande av en autentisering. Klienten initierar att skicka förfrågningar när den är redo (nödvändigt) att flytta till ett nytt tillstånd.

Under behandlingen av kundförfrågningar anses kunden vara i ett övergångstillstånd . Varje enskilt applikationstillstånd representeras av länkar som kan anropas nästa gång klienten träffar.

3. Cachning

Precis som med World Wide Web kan klienter, såväl som mellanvärdar, cachelagra serversvar. Serversvar måste i sin tur vara explicit eller implicit markerade som cachebara eller icke-cachelagrade för att förhindra att klienter tar emot inaktuella eller felaktiga data som svar på efterföljande förfrågningar. Korrekt användning av cachning kan delvis eller helt eliminera vissa klient-server-interaktioner, vilket ytterligare ökar systemets prestanda och skalbarhet.

4. Gränssnittslikformighet

Att ha ett enhetligt gränssnitt är ett grundläggande designkrav för REST-tjänster [3] . Enade gränssnitt gör att var och en av tjänsterna kan utvecklas oberoende.

Enade gränssnitt är föremål för följande fyra begränsningar [10] [11] :

Resursidentifiering
Alla resurser identifieras i förfrågningar, till exempel med hjälp av URI:er i Internetsystem. Resurser är begreppsmässigt åtskilda från vyer som returneras till kunder. En server kan till exempel skicka data från en databas som HTML , XML eller JSON , varken är en lagringstyp på serversidan.

Manipulera resurser genom en representation
Om en klient lagrar en representation av en resurs, inklusive metadata, har den tillräckligt med information för att ändra eller ta bort resursen.

"Självbeskrivande" meddelanden
Varje meddelande innehåller tillräckligt med information för att förstå hur det ska behandlas. Till exempel kan meddelandehanteraren (parser) som behövs för att extrahera data anges i listan över MIME-typer [3] .

Hypermedia som ett sätt att ändra applikationstillstånd ( HATEOAS )
Klienter ändrar systemtillstånd endast genom åtgärder som är dynamiskt definierade i hypermedia på servern (t.ex. hyperlänkar i hypertext ). Med undantag för enkla applikationsingångspunkter kan en klient inte anta att någon operation är tillgänglig på någon resurs om den inte har informerats om det i tidigare förfrågningar till servern. Det finns inget universellt format för att tillhandahålla länkar mellan resurser, webblänkning ( RFC 5988 -> RFC 8288 ) och JSON Hypermedia API Language Archived 27 juni 2014 at the Wayback Machine är två populära format för att tillhandahålla länkar i REST HYPERMEDIA-tjänster.

5. Lager

Klienten kan vanligtvis inte exakt avgöra om den kommunicerar direkt med servern eller med en mellannod, på grund av nätverkens hierarkiska struktur (vilket innebär att en sådan struktur bildar lager ). Användningen av mellanliggande servrar kan öka skalbarheten genom lastbalansering och distribuerad cachelagring . Mellanliggande noder kan också omfattas av en säkerhetspolicy för att säkerställa informationens konfidentialitet [12] .

6. Kod på begäran (valfri begränsning)

REST kan tillåta klientfunktionalitet att utökas genom att ladda ner kod från servern i form av applets eller skript . Fielding menar att den ytterligare begränsningen tillåter att en arkitektur utformas som stöder önskad funktionalitet i det allmänna fallet, men kanske med undantag i vissa sammanhang.

Fördelar

Roy Fielding påpekade att applikationer som inte uppfyller ovanstående villkor inte kan kallas REST-applikationer. Om alla villkor är uppfyllda kommer, enligt hans mening, ansökan att få följande förmåner [3] [7] :

Anteckningar

  1. ↑ Vad är REST API  (ryska)  ? . Hämtad 11 augusti 2021. Arkiverad från originalet 11 augusti 2021.
  2. ↑ Mashnin Timur Sergeevich. Java Platform Web Services Technology. - BHV-Petersburg, 2012. - S. 115. - 560 sid. — ISBN 978-5-9775-0778-3 .
  3. ↑ 1 2 3 4 5 6 7 8 9 10 Kapitel 5 i Roy Fieldings avhandling "Representational State Transfer (REST)" Arkiverad 13 maj 2021 på Wayback Machine
  4. ↑ 1 2 Fielding diskuterar definitionen av REST-termen . tech.groups.yahoo.com. Hämtad 28 november 2013. Arkiverad från originalet 22 oktober 2010.
  5. ↑ Fielding-avhandling: KAPITEL 5: Representativ statlig överföring (REST) ​​. www.ics.uci.edu. Hämtad 1 december 2015. Arkiverad från originalet 13 maj 2021.
  6. ↑ rest-discuss : Meddelande: Re: [rest-discuss RFC for REST?] (11 november 2009). Hämtad 1 december 2015. Arkiverad från originalet 11 november 2009.
  7. ↑ 1 2 Thomas Erl, Benjamin Carlyle, Cesare Pautasso, Raj Balasubramanian. 5.1 // SOA med REST. - Prentice Hall, 2013. - ISBN 978-0-13-701251-0 .
  8. ↑ Thomas Erl, Benjamin Carlyle, Cesare Pautasso, Raj Balasubramanian. 5.1 // SOA med 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 > . Hämtad 18 januari 2011. Arkiverad 19 februari 2012 på Wayback Machine 
  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, OA . Vavilov Journal of Genetics and Breeding, vol. 16, N 4/1, 2012
  12. ↑ Hartley Brody. Hur HTTPS säkrar anslutningar: Vad alla webbutvecklare bör  veta . Arkiverad från originalet den 24 december 2015.

Litteratur

Länkar

  Gå till Wikidata-objektet  I bibliografiska kataloger