Representatieve staatsoverdracht

Van Wikipedia, de gratis encyclopedie
Spring naar navigatie Spring naar zoeken

Representational State Transfer (afgekort tot REST ) is een paradigma voor de software-architectuur van gedistribueerde systemen , vooral voor webservices . REST is een abstractie van de structuur en het gedrag van het World Wide Web . REST streeft naar een bouwstijl die beter aansluit bij de eisen van het moderne web. Het belangrijkste verschil tussen REST en andere bouwstijlen is de eis van een uniforme interface (zie het hoofdstuk Principes ).

Het doel van REST is voornamelijk machine-naar-machine communicatie . REST is een eenvoudig alternatief voor vergelijkbare methoden zoals SOAP en WSDL en de verwante methode RPC In tegenstelling tot veel verwante architecturen codeert REST geen methode-informatie in de URI , omdat de URI de locatie en naam van de bron specificeert, maar niet de functionaliteit die de Aanbiedende webservice aan de bron biedt. Het voordeel van REST is dat een groot deel van de infrastructuur die nodig is voor REST (bijvoorbeeld web- en applicatieservers, HTTP- compatibele clients, HTML- en XML- parsers, beveiligingsmechanismen) al beschikbaar is op het WWW, en veel van de webservices zijn op zich REST-compatibel. Een resource kan worden weergegeven met behulp van verschillende soorten media , ook wel een representatie van de resource genoemd .

Een online service die alleen ongewijzigde pagina-inhoud aanbiedt op basis van de HTTP-internetstandaard is al REST-compliant. Dynamisch gegenereerde pagina's volgen dit paradigma echter vaak niet. Zo bieden nieuwssites voortdurend wisselende informatie met zowel verschillende formaten als content die moeilijk automatisch te verwerken is. Als het formaat ongewijzigd bleef, zou aan een belangrijke REST-eigenschap worden voldaan. Zo zou een website waarop de huidige tijd altijd in hetzelfde formaat kan worden opgeroepen, REST-compliant zijn.

De term "Representational State Transfer" is bedoeld om de overgang van de huidige status naar de volgende status van een aanvraag te illustreren. Deze toestandsovergang vindt plaats door de overdracht van de gegevens die de volgende toestand vertegenwoordigen. [1]

verhaal

Het REST-paradigma is voortgekomen uit het HTTP- objectmodel dat in 1994 door Roy Fielding is ontworpen. Fielding ontwikkelde zijn idee van een verenigd concept door de jaren heen totdat hij de REST-architectuurstijl publiceerde als onderdeel van zijn proefschrift in 2000. [2] Het programmeerparadigma van de "RESTful Application" werd echter vaak verkeerd geïmplementeerd en vindt pas sinds 2014 ingang in de wereld van het World Wide Web. Fielding gaat in zijn werk in op de verschillende eisen die van belang zijn voor de webarchitectuur.

Principes

De architectuurstijl verwijst naar zes eigenschappen die een dienst moet hebben. Er wordt niet gespecificeerd hoe deze principes moeten worden geïmplementeerd. Fielding beschrijft de voor- en nadelen van elk architectuurprincipe. [3]

Client server

De algemene eis is dat alle eigenschappen van de client-server architectuur van toepassing zijn. De server biedt een service die desgewenst door de klant kan worden aangevraagd. Het belangrijkste voordeel van deze vereiste is de eenvoudige schaalbaarheid van de servers, omdat ze onafhankelijk van de client werken. Hierdoor kunnen de twee componenten ook met verschillende snelheden worden ontwikkeld.

staatloosheid

Elk REST-bericht bevat alle informatie die nodig is voor de server of client om het bericht te begrijpen. Noch de server, noch de toepassing mag statusinformatie tussen twee berichten opslaan. Daarom wordt het een staatloos (Engels: staatloos) protocol genoemd. Elk verzoek van een client aan de server staat op zichzelf omdat het alle informatie bevat over de applicatiestatus die de server nodig heeft om het verzoek te verwerken.

Staatloosheid in de hier beschreven vorm bevordert de schaalbaarheid van een webservice. Inkomende verzoeken kunnen bijvoorbeeld gemakkelijk naar elke machine worden gedistribueerd tijdens de taakverdeling : aangezien elk verzoek op zichzelf staat en toepassingsinformatie daarom alleen aan de clientzijde wordt opgeslagen, is er geen sessiebeheer vereist aan de serverzijde. In de praktijk gebruiken veel op HTTP gebaseerde applicaties daarom cookies en andere technieken om statusinformatie aan de clientzijde te houden. De faalveiligheid wordt ook begunstigd omdat de staatloosheid vereist dat transactiegegevensoverdracht plaatsvindt in een enkele paginaweergave. De staatloosheid heeft als nadeel dat de netwerkprestaties verslechteren. Aangezien alle informatie voor begrip bij elke query moet worden verzonden, zijn complexere query's nodig dan wanneer de server de interacties zou onthouden.

Caching

Er dient gebruik gemaakt te worden van HTTP caching , maar het volgende is van toepassing: Een request die niet gedaan hoeft te worden is de snelste request. Fielding heeft het nadeel dat de client kan terugvallen op verouderde cachegegevens in plaats van de nieuwe bron op te vragen.

Uniforme interface

Dit is de belangrijkste onderscheidende factor van alle andere bouwstijlen. Deze bestaat uit vier andere eigenschappen. Het doel is de uniformiteit van de interface en daarmee het gebruiksgemak.

Adresseerbaarheid van bronnen

Alle informatie die is geïdentificeerd door een URI, wordt gemarkeerd als een resource. Elke RESTful-service heeft een uniek adres, de Uniform Resource Locator (URL). Dit "straat- en huisnummer in het netwerk" standaardiseert het toegangspad om een ​​webservice aan te bieden voor een groot aantal toepassingen (klanten). Consistente adressering maakt het ook gemakkelijker om een ​​webservice te blijven gebruiken als onderdeel van een mashup .

Vertegenwoordigingen voor het wijzigen van resources

De op één adres toegankelijke diensten kunnen verschillende vormen van vertegenwoordiging hebben. Een RESTful-server kan verschillende representaties van een resource leveren, afhankelijk van wat de applicatie vraagt, b.v. B. in verschillende talen of formaten ( HTML , JSON of XML ) of de beschrijving of documentatie van de dienst. De verandering van een resource (d.w.z. de huidige status) mag alleen plaatsvinden via een representatie.

Zelfbeschrijvende berichten

REST-berichten moeten zichzelf beschrijven. Dit omvat het gebruik van standaardmethoden. Middelen kunnen worden gemanipuleerd met behulp van deze standaardmethoden. De HTTP-werkwoorden zijn hier een voorbeeld; Zie hieronder voor details.

"Hypermedia als de motor van de applicatiestatus" (HATEOAS)

Volgens Fielding is dit de belangrijkste eigenschap; zie hieronder .

Meerlagige systemen

De systemen dienen in meerdere lagen te worden gestructureerd. Dit betekent dat het voldoende is om de gebruiker simpelweg een interface aan te bieden. De achterliggende niveaus kunnen verborgen blijven, waardoor de architectuur als geheel wordt vereenvoudigd. De voordelen hiervan zijn de betere schaalbaarheid van de server, evenals een mogelijke inkapseling door firewalls. Cachegeheugen aan de grenzen (bijvoorbeeld van de server naar het web) kan de efficiëntie van de verzoeken verhogen; zie caching.

Code op aanvraag (optioneel)

Deze vereiste van Fielding is optioneel. Code-on-demand betekent dat code alleen naar de klant kan worden verzonden voor lokale uitvoering wanneer dat nodig is.
Een voorbeeld hiervan is de overdracht van JavaScript-code in een HTML-weergave.

implementatie

Een stateless client-server protocol wordt gebruikt om het REST-paradigma te implementeren. De belangrijkste protocollen voor de applicatielaag die worden gebruikt, zijn HTTP en HTTPS . Dit komt onder andere door het feit dat deze zich op het WWW hebben gevestigd, een relatief eenvoudige structuur hebben en compatibel zijn met bijna elke firewall . REST verenigt de interface tussen systemen tot een beheersbare en gestandaardiseerde set van acties met betrekking tot het verwachte gedrag. Wat deze acties zijn, wordt niet gespecificeerd in REST, maar alle acties worden over het algemeen gedefinieerd, meestal door de gebruikte applicatielaagprotocollen.

Hoewel REST als abstractie van het WWW geen speciale implementatie of een speciaal protocol vereist, kan worden opgemerkt dat HTTP bijna uitsluitend wordt gebruikt, wat ook het aantal acties definieert.

Als toegang wordt verkregen via HTTP, geeft de gebruikte HTTP-methode, waaronder GET , POST , PUT en DELETE , aan welke servicebewerking vereist is. HTTP vereist dat GET "veilig" ( Engels om veilig te zijn) nodig heeft, wat betekent dat deze methode alleen informatie verkrijgt en geen andere effecten veroorzaakt. De methoden GET , HEAD , PUT en DELETE moeten volgens de HTTP-specificatie idempotent zijn, wat in deze context betekent dat meerdere verzendingen van hetzelfde verzoek geen ander effect hebben dan een enkele aanroep. [4]

REST-clients die HTTP gebruiken, kunnen de volgende opdrachten geven om bronnen aan te vragen of te wijzigen:

opdracht
(HTTP-methode)
Beschrijving Opmerkingen
KRIJGEN Vraagt ​​de opgegeven bron op bij de server. GET heeft geen bijwerkingen. De status op de server wordt niet gewijzigd, daarom wordt GET secure genoemd . [n 1]
POSTKANTOOR Voegt een nieuwe (sub)resource in onder de opgegeven resource. Aangezien de nieuwe resource nog geen URI heeft, adresseert de URI de resource op een hoger niveau. Als resultaat wordt de nieuwe bronkoppeling teruggestuurd naar de client. In bredere zin kan POST ook worden gebruikt om bewerkingen in kaart te brengen die niet door een andere methode worden gedekt. [n2]
NEERZETTEN De opgegeven resource is gemaakt. Als de bron al bestaat, wordt deze gewijzigd. [n3]
PATCH [n 4] Een deel van de opgegeven bron is gewijzigd. Bijwerkingen zijn hier toegestaan. [n 5]
VERWIJDEREN Verwijdert de opgegeven bron. [n3]
HOOFD Verzoekt metadata over een bron. [n 5] [n 1]
OPTIES Controleert welke methoden beschikbaar zijn voor een resource. [n 5] [n 1]
AANSLUITEN Wordt gebruikt om het verzoek door een TCP-tunnel te leiden. Meestal gebruikt om een ​​HTTPS-verbinding tot stand te brengen via een HTTP-proxy. [n 5] [n 1] [n 6]
SPOOR Retourneert het verzoek zoals ontvangen door de doelserver. Wordt bijvoorbeeld gebruikt om wijzigingen in het verzoek door proxyservers vast te stellen. [n 5] [n 1] [n 6]
  1. a b c d e nullipotent . Het aanroepen van deze methoden heeft geen bijwerkingen.
  2. niet idempotent. Door opnieuw aan te roepen, wordt voor elke aanroep een nieuw object gemaakt met dezelfde URI in plaats van hetzelfde object te retourneren.
  3. a b idempotent . De eerste aanroep van deze methoden met een specifieke URI heeft bijwerkingen. Een herhaalde oproep met dezelfde URI leidt tot geen verdere bijwerkingen.
  4. zie RFC 5789
  5. a b c d e optioneel. Niet vereist voor CRUD- bewerkingen.
  6. a b Het implementeren van deze methoden kan gevolgen hebben voor de beveiliging van de applicatie.

Afhankelijk van de implementatie kunnen andere HTTP-commando's worden ondersteund. Deze omvatten COPY , MOVE , MKCOL , LOCK en UNLOCK het WebDAV- protocol [5] , evenals LINK en UNLINK van RFC 2068 . Bij communicatie via UDP kan de CoAP van RFC 7252 ook worden gebruikt in plaats van HTTP, dat iets andere betekenissen heeft voor GET , POST , PUT en DELETE .

veiligheid

Het paradigma vereist dat alle informatie die een toepassing nodig heeft om de paginastatus te herstellen, in het verzoek wordt opgenomen. De URI identificeert de bron, terwijl de HTTP-header informatie kan bevatten zoals het type toegang (GET, PUT), retourformaat of authenticatie.

REST kan worden gebruikt voor websites en webservices die geen authenticatie vereisen of die op andere manieren kunnen worden bereikt (bijvoorbeeld door het controleren van het IP-adres , HTTP-authenticatie of TLS / HTTPS- certificaatcontrole), waardoor veel use-cases al kunnen worden afgedekt . Als alternatief kunnen ook op tokens gebaseerde methoden zoals HMAC , OAuth , JSON Web Token of OpenID worden gebruikt.

Aangezien REST - in tegenstelling tot SOAP met WS-Security - zelf geen encryptiemethodes definieert, wordt voor veiligheidskritieke berichten een versleuteld transportprotocol zoals HTTPS gebruikt.

Door de HTTP-methoden te gebruiken, is het voor firewalls mogelijk om het verzoek te begrijpen, te filteren en te loggen. Een voorbeeld hiervan is dat alle PUT-verzoeken van een externe bron kunnen worden afgewezen. Hierin verschilt REST van bijvoorbeeld SOAP .

Versiebeheer

Om een ​​REST-service te versies, zijn er verschillende varianten om uit te kiezen: via het DNS-adres, URL en via HTTP-header.

Bij DNS-versiebeheer wordt de versie behandeld als onderdeel van de hostnaam.

http://v1.api.foo.com/customer/1234
http://v1_1.api.foo.com/customer/1234
http://v2.api.foo.com/customer/1234
http://v2_2.api.foo.com/customer/1234

Deze variant gaat meestal gepaard met veel moeite vanwege het beheer in de DNS. Het wordt daarom in de praktijk zelden aangetroffen.

Bij URL-versiebeheer wordt de versie van de interface gespecificeerd in het pad van de URL:

http://foo.com/api/v1/customer/1234
http://foo.com/api/v1.1/customer/1234
http://foo.com/api/v2.0/customer/1234
http://foo.com/api/v2.2/customer/1234

Versiebeheer via de URL is de meest voorkomende variant.

Bij versiebeheer via de HTTP-header wordt de versie gespecificeerd in de Accept HTTP-header:

 GET / api / klant / 1234 HTTP / 1.1
Gastheer: foo.com
Accepteren: applicatie / xml, applicatie / json; versie = 1

Nadat een nieuwe versie van de dienst beschikbaar is gesteld, moet de oude versie van het eindpunt nog een bepaalde tijd beschikbaar blijven om de gebruiker de tijd te geven om over te stappen. Een clienttoepassing moet automatisch kunnen herkennen dat het eindpunt verouderd is zonder het gebruik van het eindpunt te beperken. Dit kan worden gedaan met behulp van een waarschuwing HTTP-header :

 HTTP / 1.1 200 OK
Datum: za, 11 maart 2017 12:28:53 GMT
Server: Apache / 2.2.14 (Win32)
Waarschuwing: 299 foo.com/api/v1 "Verouderde API: gebruik in plaats daarvan foo.com/api/v1.1. Oude API onderhouden tot 2017-06-02"
Inhoud-Lengte: 88
Inhoudstype: applicatie / json
Verbinding gesloten

De klant dient de waarschuwing in het logboek en in een OpsDB te loggen , zodat de klantoperator tijdig kan overstappen naar de nieuwe API.

Als het oude eindpunt nog wordt aangeboden, moet het nieuwe eindpunt te vinden zijn via een HTTP-redirect op het oude adres:

 GET / api / v1 / klant / 1234 HTTP / 1.1
Gastheer: foo.com
Accepteren: applicatie / xml, applicatie / json
 HTTP / 1.1 302 Gevonden
Locatie: foo.com/api/v1.1/customer/1234

In principe is het aan te raden om via monitoring te controleren of dit endpoint nog actief wordt gebruikt alvorens een verouderd endpoint vrij te geven. Daarnaast moet OpsDB worden gebruikt om te controleren of het een eindpunt is dat slechts zelden wordt gebruikt (bijvoorbeeld driemaandelijks).

HATEOAS

HATEOAS staat voor Hypermedia as the Engine of Application State en is een ontwerpprincipe van REST-architecturen. Met HATEOAS navigeert de client van een REST-interface uitsluitend via URL's die door de server worden aangeleverd. [6]

Afhankelijk van de gekozen weergave worden de URI's beschikbaar gesteld via hypermedia , b.v. B.

  • in de vorm van “href” en “src” attributen voor HTML- documenten of HTML-fragmenten, of
  • in JSON- of XML-attributen / elementen gedefinieerd en gedocumenteerd voor de respectieve interface.

Vanuit een abstract oogpunt vertegenwoordigen HATEOAS-compatibele REST-services een eindige machine , waarvan de status wordt gewijzigd door navigatie met behulp van de verstrekte URI's.

HATEOAS garandeert een losse verbinding en de interface kan worden gewijzigd. Een op SOAP gebaseerde webservice daarentegen communiceert via een vaste interface. Om de service te wijzigen, moet hier een nieuwe interface worden verstrekt en gedefinieerd in de interfacebeschrijving (een WSDL- document). Registratiedatabases of vergelijkbare infrastructuren, b.v. B. zijn vereist voor Remote Function Call , zijn niet vereist voor HATEOAS.

Er zijn verschillende standaarden voor het in kaart brengen van HATEOAS. Deze omvatten: [7]

voorbeeld

Het voorbeeld toont een GET-verzoek dat accountgegevens in JSON-indeling oproept:

 GET / accounts / 123abc HTTP / 1.1
Host : bank.voorbeeld.com
Accepteren : applicatie / json
...

Het antwoord kan dan als volgt zijn:

 HTTP / 1.1 200 OK
Inhoudstype : applicatie / json
Inhoud-Lengte : ...

{
   "rekening" : {
      "account_id" : "123abc" ,
       "balans" : {
          "valuta" : "EUR" ,
          "waarde" : 100.0
       },
       "links" : {
          "storting" : "/ rekeningen / 123abc / storting" ,
          "opnemen" : "/ rekeningen / 123abc / intrekken" ,
          "overboeking" : "/ rekeningen / 123abc / overboeking" ,
          "sluiten" : "/ rekeningen / 123abc / sluiten"
       }
   }
}

Dit antwoord bevat vier mogelijke links: deposit , withdraw , transfer en close . Als de rekening rood staat, kan er alleen geld op de rekening worden gestort, maar niets kan worden gedebiteerd of overgedragen en de rekening kan niet meer worden geannuleerd. Het antwoord voor dit voorbeeld kan er dus als volgt uitzien:

 HTTP / 1.1 200 OK
Inhoudstype : applicatie / json
Inhoud-Lengte : ...

{
   "rekening" : {
      "account_id" : "123abc" ,
       "balans" : {
           "valuta" : "EUR" ,
           "waarde" : -100.0
       },
       "links" : {
          "storting" : "/ rekeningen / 123abc / storting"
       }
   }
}

Richardson volwassenheidsmodel

Het Richardson Maturity Model (RMM, Duits Richardson Maturity Model ) is een door Leonard Richardson ontwikkelde maatstaf die aangeeft hoe strikt een dienst REST implementeert.

Richardson-rijpheidsmodel (8)
Niveau eigenschappen
0
  • gebruikt XML-RPC of SOAP
  • de service wordt aangesproken via één URI
  • gebruikt een enkele HTTP-methode (vaak POST)
1
  • gebruikt verschillende URI's en bronnen
  • gebruikt een enkele HTTP-methode (vaak POST)
2
  • gebruikt verschillende URI's en bronnen
  • gebruikt verschillende HTTP-methoden
3e
  • is gebaseerd op HATEOAS en gebruikt daarom hypermedia voor navigatie
  • gebruikt verschillende URI's en bronnen
  • gebruikt verschillende HTTP-methoden

Onderscheid van andere communicatiemechanismen

REST is een programmeerparadigma dat met verschillende mechanismen kan worden geïmplementeerd. Nieuw is het gebruik van zoveel mogelijk HTTP- methoden in verband met de uit te voeren actie. Daarentegen wordt SOAP bijvoorbeeld voornamelijk gebruikt met de POST-methode. Het verschil zit hem meer in het bredere gebruik van HTTP als protocol en URI als identificatiemechanisme voor concrete objecten. In het verleden werden SOAP-interfaces daarentegen opgezet op basis van RPC . De zwakke punten van SOAP zijn onder meer de vrij grote overhead met veel meta en weinig gebruikersgegevens, evenals de rekenintensieve constructie van XML-berichten. Daarnaast zijn er inmiddels tal van substandaarden die moeilijk bij te houden zijn. [9] De strenge eisen van REST helpen daarentegen om goed gestructureerde services te bouwen en het gebruik van schone URL's te ondersteunen .

Zie ook

literatuur

  • Leonard Richardson, Sam Ruby: webservices met REST . O'Reilly Verlag, 2007, ISBN 978-3-89721-727-0 .
  • Stefan Tilkov et al.: REST en HTTP . Ontwikkeling en integratie volgens de bouwstijl van het web. 3e, bijgewerkte en uitgebreide editie. dpunkt Verlag, 2015, ISBN 978-3-86490-120-1 .

web links

Individueel bewijs

  1. ^ Roy Fielding: 6: Ervaring en evaluatie. In: Architecturale stijlen en het ontwerp van netwerkgebaseerde software-architecturen. 2000, geraadpleegd op 15 juni 2015 .
  2. ^ Roy Thomas Fielding: architecturale stijlen en het ontwerp van netwerkgebaseerde software-architecturen - proefschrift . 2000 ( volledige tekst [PDF; geraadpleegd op 6 januari 2021]).
  3. ^ Roy Thomas Fielding: architecturale stijlen en het ontwerp van netwerkgebaseerde software-architecturen - proefschrift . 2000, blz.   79   ff .
  4. Fielding, et al.: 9 Methodedefinities. In: Hypertext Transfer Protocol - HTTP / 1.1. 2004, geraadpleegd op 1 juli 2010 .
  5. ^ WebDAV-methoden. In: MSDN. Microsoft, juni 2007, geraadpleegd op 13 februari 2016 .
  6. Andreas Würl, Jörg Adler: Hoogste mate van volwassenheid voor RUST met HATEOAS. Heise , 6 december 2016, geraadpleegd op 6 januari 2021 .
  7. Kevin Sookocheff: over het kiezen van een hypermediatype voor uw API - HAL, JSON-LD, Collection + JSON, SIREN, Oh My! 11 maart 2014, geraadpleegd op 11 juni 2017 .
  8. ^Martin Fowler : Richardson Maturity Model. 18 maart 2010, geraadpleegd op 7 april 2013 (Engels, uitleg van het REST Maturity Model (RMM)).
  9. Martin Helmich: RESTful Webservices (1): Wat is dat eigenlijk? 12 maart 2013. Ontvangen 16 november 2017 .