HVILE

Den aktuelle version af siden er endnu ikke blevet gennemgået af erfarne bidragydere og kan afvige væsentligt fra den version , der blev gennemgået den 4. maj 2022; checks kræver 5 redigeringer .

REST (fra engelsk . Representational  State Transfer - " transmission  af en repræsentativ stat" eller "transmission af en" selvbeskrivende "stat") er en arkitektonisk interaktionsstil mellem komponenter i en distribueret applikation i et netværk . REST er med andre ord et sæt regler for, hvordan en programmør organiserer kodningen af ​​en serverapplikation, så alle systemer nemt kan udveksle data, og applikationen kan skaleres. [1] REST er et konsekvent sæt af begrænsninger, der skal tages i betragtning, når man designer et distribueret hypermediesystem . I visse tilfælde ( onlinebutikker ,søgemaskiner , andre datadrevne systemer) dette resulterer i forbedret ydeevne og forenklet arkitektur. I bred forstand[ klargør ] Komponenter i REST interagerer på samme måde som klienter og servere interagerer på World Wide Web . REST er et alternativ til RPC [2] .

På internettet kan et fjernprocedurekald være en normal HTTP - anmodning (normalt GET eller POST ; sådan en anmodning kaldes en "REST-anmodning" ) , og de nødvendige data sendes som anmodningsparametre [3] [4] .

For webtjenester, der er bygget med REST i tankerne (det vil sige, at de ikke overtræder de begrænsninger, det pålægger), bruges udtrykket " RESTful ".

I modsætning til webtjenester (webtjenester) baseret på SOAP er der ingen "officiel" standard for RESTful web API. Pointen er, at REST er en arkitektonisk stil , mens SOAP er en protokol. Selvom REST ikke er en standard i sig selv, bruger de fleste RESTful-implementeringer standarder som HTTP , URL , JSON og, mindre almindeligt, XML .

Historien om udtrykket

Selvom dette koncept ligger selve grundlaget for World Wide Web , blev udtrykket "REST" introduceret af Roy Fielding , en af ​​skaberne af " HTTP "-protokollen, først i 2000 [4] . I sin afhandling "Architectural Styles and the Design of Network-based Software Architectures" [5] ved University of California, Irvine [3] tilvejebragte han en teoretisk ramme for den måde , klienter og servere interagerer på på World Web , og abstraherer det og kalder det "repræsentativ statsoverførsel" ("Repræsentativ statsoverførsel " ). Fielding beskrev konceptet med at bygge en distribueret applikation, hvor hver anmodning (REST-anmodning) fra klienten til serveren indeholder omfattende information om det ønskede serversvar (ønsket repræsentativ tilstand), og serveren er ikke forpligtet til at gemme information om tilstanden af klienten ("klientsession").

"REST"-stilen udviklede sig parallelt med " HTTP 1.1 " udviklet i 1996-1999 og byggede på det eksisterende " HTTP 1.0"-design udviklet i 1996 [6] .

Egenskaber for REST-arkitekturen

Arkitektoniske egenskaber, der afhænger af de restriktioner, der er pålagt REST-systemer:

Roy Fielding, en af ​​hovedforfatterne af HTTP-protokolspecifikationen, beskriver REST-arkitekturens indvirkning på skalerbarheden som følger:

REST arkitekturkrav

Der er seks obligatoriske begrænsninger for at bygge distribuerede REST-applikationer ifølge Fielding [3] [7] .

Disse begrænsninger er obligatoriske for REST-systemer [8] [9] . De pålagte begrænsninger bestemmer, hvordan serveren fungerer i forhold til, hvordan den kan behandle og reagere på klientanmodninger. Ved at operere inden for disse begrænsninger opnår systemet ønskværdige egenskaber såsom ydeevne, skalerbarhed, enkelhed, tilpasningsevne, portabilitet, sporbarhed og pålidelighed.

Hvis serviceapplikationen overtræder nogen af ​​disse restriktive betingelser, kan systemet ikke betragtes som et REST-system [3] .

Obligatoriske betingelser-begrænsninger er:

1. Klient-server model

Den første begrænsning, der gælder for hybridmodellen, er at bringe arkitekturen til klient-server-modellen. Behovsafgrænsning er princippet bag denne pålagte begrænsning. Adskillelse af behovene for klientgrænsefladen fra behovene på serveren, der gemmer dataene, øger portabiliteten af ​​klientgrænsefladekoden til andre platforme, mens en forenkling af back-end forbedrer skalerbarheden. Den måske største indvirkning på World Wide Web er selve afgrænsningen, som tillader separate dele at udvikle sig uafhængigt af hinanden, hvilket understøtter internettets udviklingsbehov fra forskellige organisationer. [3]

2. Manglende tilstand

Interaktionsprotokollen mellem klienten og serveren kræver følgende betingelse: i perioden mellem klientanmodninger gemmes ingen information om klientens tilstand på serveren ( Stateless Protocol eller "Stateless Protocol"). Alle anmodninger fra klienten skal udformes på en sådan måde, at serveren modtager al den nødvendige information for at fuldføre anmodningen. Sessionstilstanden gemmes på klientsiden [3] . Sessionstilstandsinformationen kan sendes af serveren til en anden tjeneste (for eksempel til en databasetjeneste) for at opretholde en stabil tilstand, for eksempel i perioden med etablering af en godkendelse. Klienten starter afsendelse af anmodninger, når den er klar (nødvendig) til at flytte til en ny tilstand.

Under behandlingen af ​​klientanmodninger anses klienten for at være i en overgangstilstand . Hver enkelt applikationstilstand er repræsenteret af links, der kan aktiveres, næste gang klienten rammer.

3. Caching

Som med World Wide Web kan klienter, såvel som mellemværter, cache serversvar. Serversvar skal til gengæld udtrykkeligt eller implicit markeres som cache- eller ikke-cachelagrede for at forhindre klienter i at modtage forældede eller forkerte data som svar på efterfølgende anmodninger. Korrekt brug af caching kan helt eller delvist eliminere nogle klient-server-interaktioner, hvilket yderligere øger systemets ydeevne og skalerbarhed.

4. Interface ensartethed

At have en samlet grænseflade er et grundlæggende designkrav for REST-tjenester [3] . Forenede grænseflader gør det muligt for hver af tjenesterne at udvikle sig uafhængigt.

Forenede grænseflader er underlagt følgende fire begrænsninger [10] [11] :

Ressourceidentifikation
Alle ressourcer identificeres i anmodninger, for eksempel ved hjælp af URI'er i internetsystemer. Ressourcer er konceptuelt adskilt fra visninger, der returneres til kunder. For eksempel kan en server sende data fra en database som HTML , XML eller JSON , hvoraf ingen af ​​dem er en lagertype på serversiden.

Manipulering af ressourcer gennem en repræsentation
Hvis en klient gemmer en repræsentation af en ressource, inklusive metadata, har den nok information til at ændre eller slette ressourcen.

"Selv-beskrivende" meddelelser
Hver meddelelse indeholder nok information til at forstå, hvordan den skal behandles. For eksempel kan meddelelsesbehandleren (parseren), der er nødvendig for at udtrække data, angives på listen over MIME-typer [3] .

Hypermedier som et middel til at ændre applikationstilstand ( HATEOAS )
Klienter ændrer kun systemtilstand gennem handlinger, der er dynamisk defineret i hypermedier på serveren (f.eks. hyperlinks i hypertekst ). Med undtagelse af simple applikationsindgangspunkter kan en klient ikke antage, at en eller anden handling er tilgængelig på en ressource, medmindre den er blevet informeret om det i tidligere anmodninger til serveren. Der er ikke noget universelt format til at levere links mellem ressourcer, weblinking ( RFC 5988 -> RFC 8288 ) og JSON Hypermedia API Language Archived 27. juni 2014 på Wayback Machine er to populære formater til at levere links i REST HYPERMEDIA-tjenester.

5. Lag

Klienten er normalt ikke i stand til nøjagtigt at afgøre, om den kommunikerer direkte med serveren eller med en mellemnode, på grund af den hierarkiske struktur af netværk (hvilket betyder, at en sådan struktur danner lag ). Brugen af ​​mellemliggende servere kan øge skalerbarheden gennem belastningsbalancering og distribueret caching . Mellemliggende knudepunkter kan også være underlagt en sikkerhedspolitik for at sikre oplysningernes fortrolighed [12] .

6. Kode efter behov (valgfri begrænsning)

REST kan tillade, at klientfunktionaliteten udvides ved at downloade kode fra serveren i form af applets eller scripts . Fielding argumenterer for, at den yderligere begrænsning gør det muligt at designe en arkitektur, der understøtter den ønskede funktionalitet i det generelle tilfælde, men måske med undtagelser i nogle sammenhænge.

Fordele

Roy Fielding påpegede, at applikationer, der ikke opfylder ovenstående betingelser, ikke kan kaldes REST-applikationer. Hvis alle betingelser er opfyldt, vil ansøgningen efter hans mening modtage følgende fordele [3] [7] :

Noter

  1. ↑ Hvad er REST API  (russisk)  ? . Hentet 11. august 2021. Arkiveret fra originalen 11. august 2021.
  2. ↑ Mashnin Timur Sergeevich. Java Platform Web Services-teknologi. - BHV-Petersburg, 2012. - S. 115. - 560 s. — ISBN 978-5-9775-0778-3 .
  3. ↑ 1 2 3 4 5 6 7 8 9 10 Kapitel 5 i Roy Fieldings afhandling "Representational State Transfer (REST)" Arkiveret 13. maj 2021 på Wayback Machine
  4. ↑ 1 2 Fielding diskuterer definitionen af ​​REST-begrebet . tech.groups.yahoo.com. Hentet 28. november 2013. Arkiveret fra originalen 22. oktober 2010.
  5. ↑ Fielding-afhandling: KAPITEL 5: Repræsentativ statsoverførsel (REST) ​​. www.ics.uci.edu. Hentet 1. december 2015. Arkiveret fra originalen 13. maj 2021.
  6. ↑ rest-discuss : Message: Re: [rest-discuss RFC for REST?] (11. november 2009). Hentet 1. december 2015. Arkiveret fra originalen 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 > . Hentet 18. januar 2011. Arkiveret 19. februar 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. Hvordan HTTPS sikrer forbindelser: Hvad enhver webudvikler bør  vide . Arkiveret fra originalen den 24. december 2015.

Litteratur

Links

  Gå til Wikidata-elementet  I bibliografiske kataloger