REST ( repræsentativ tilstandsoverførsel ) er en stil af softwarearkitektur, der definerer et sæt begrænsninger, der skal bruges til at oprette webtjenester . REST-arkitekturstil-webtjenester, også kendt som RESTful- webtjenester , etablerer interoperabilitet mellem computere på Internettet . REST-webtjenester tillader anmodende systemer at manipulere webressourcer gennem deres tekstrepræsentationer gennem et sæt ensartede, foruddefinerede statsløse operationer . Andre typer webtjenester, såsom SOAP- webtjenester, udsætter deres egne sæt vilkårlige operationer.
Webressourcer blev først defineret på World Wide Web som dokumenter eller filer identificeret ved deres URL . Imidlertid har de i dag en meget mere generisk og abstrakt definition, der inkluderer alt eller en enhed, der kan identificeres, navngives, adresseres eller styres på enhver måde på nettet. I en REST-webservice producerer anmodninger til URI for en ressource et svar, hvis krop er formateret i HTML , XML , JSON eller et andet format. Svaret kan bekræfte, at den lagrede ressource er ødelagt, og den kan give hyperlinks til andre relaterede ressourcer eller samling af ressourcer. Når HTTP- protokollen bruges, som det ofte er tilfældet, er de tilgængelige HTTP-metoder GET, HEAD, POST, PUT, PATCH, DELETE, CONNECT, OPTIONS og TRACE.
Ved brug af statsløs protokol og standardoperationer sigter REST-systemer mod lydhørhed, pålidelighed og skalerbarhed ved at genbruge komponenter, der kan administreres og opdateres uden at påvirke det samlede system, selv under dets drift.
Udtrykket repræsentativ statsoverførsel blev først defineret i 2000 af Roy Fielding i kapitel 5 i hans doktorafhandling . Fieldings afhandling forklarede principperne for REST, der tidligere var kendt som "HTTP-objektmodellen" siden 1994, og som blev brugt i udviklingen af HTTP 1.1- og URI-standarderne. Udtrykket er beregnet til at henvise til, hvordan en veldesignet webapplikation opfører sig: det er et netværk af ressourcer (en virtuel tilstandsmaskine), inden for hvilken brugeren bevæger sig ved at vælge ressourceidentifikatorer såsom http: //www.example .com / articles / 21 og ressourcehandlinger såsom GET eller POST (applikationstilstandsovergange), der overfører en repræsentation af den næste ressource (den nye applikationstilstand) til brugeren, der skal bruges.
Roy Fielding definerede REST i 2000 i sin doktorafhandling Architectural Styles and the Design of Network-based Software Architectures ved University of California i Irvine . Der udviklede han REST-stil af arkitektur sammen med HTTP 1.1- protokollen fra 1996 til 1999, baseret på den eksisterende HTTP 1.0-model fra 1996.
I et retrospektivt kig på udviklingen af REST sagde Fielding:
Under hele HTTP-standardiseringsprocessen blev jeg opfordret til at forsvare designvalgene på Internettet. Det er en ekstremt vanskelig ting at gøre inden for en proces, der accepterer forslag fra enhver om et emne, der hurtigt blev centrum for en hel industri. Jeg havde kommentarer fra over 500 udviklere, hvoraf mange var fremtrædende ingeniører med årtiers erfaring, og jeg var nødt til at forklare alt fra de mest abstrakte forestillinger om webinteraktion til de fineste detaljer i HTTP-syntaks. Denne proces finpudset min model ned til et kernesæt af principper, egenskaber og begrænsninger, der nu kaldes REST.
”Under HTTP-standardiseringsprocessen blev jeg opfordret til at forsvare de arkitektoniske valg på Internettet. Det er en ekstremt kompliceret opgave, da proceduren accepterer indlæg fra enhver om et emne, der hurtigt blev fokus for en hel branche. Jeg modtog feedback fra over 500 udviklere, hvoraf mange var kendte ingeniører med årtiers erfaring og måtte forklare alt fra de mest abstrakte forestillinger om webinteraktioner til de finere detaljer om websyntaks. HTTP. Denne procedure reducerede min model til et grundlæggende sæt principper, egenskaber og begrænsninger, som i dag kaldes REST. "
Seks arkitektoniske begrænsninger definerer et REST-system. Disse begrænsninger begrænser, hvordan serveren kan behandle og svare på klientanmodninger, så systemet ved at handle inden for disse begrænsninger får ønskelige ikke-funktionelle egenskaber, såsom ydeevne, skalerbarhed, enkelhed, skalerbarhed osv. Synlighed, bærbarhed og pålidelighed. Et system, der overtræder en af disse begrænsninger, kan ikke anses for at overholde REST-arkitekturen.
Ansvar er adskilt mellem klienten og serveren. Afkobling af brugergrænsefladen fra datalagring forbedrer portabiliteten af brugergrænsefladen på tværs af flere platforme. Systemets skalerbarhed forbedres også ved forenkling af serverkomponenterne. Men måske endnu vigtigere for Internettet giver adskillelse komponenter mulighed for at udvikle sig uafhængigt og understøtter således de mange organisatoriske domæner, der er nødvendige for at skalere Internettet.
Klient - server kommunikation foregår uden at holde tilstanden af kommunikationen session på serveren mellem to på hinanden anmodninger. Sessionens tilstand opbevares af klienten og transmitteres med hver nye anmodning. Klientanmodninger indeholder derfor alle de oplysninger, der er nødvendige for, at serveren kan svare på dem. Synligheden af interaktioner mellem komponenter forbedres, da anmodningerne er komplette. Tolerance for fiasko er også større. Desuden giver det faktum, at den ikke behøver at opretholde en permanent forbindelse mellem klienten og serveren, serveren at svare på andre anmodninger fra andre klienter uden at mætte alle dens kommunikationsporte, hvilket forbedrer ydeevnen.
En almindelig undtagelse fra denne tilstandsløse tilstand er imidlertid styring af klientgodkendelse, så sidstnævnte ikke behøver at returnere disse oplysninger til hver af sine anmodninger.
Kunder og mellemliggende servere kan cache svar. Svar skal derfor implicit eller eksplicit defineres som cacheable eller ej for at forhindre klienter i at hente uaktuelle eller upassende data som svar på efterfølgende anmodninger. Velstyret caching eliminerer delvis klient - serverinteraktioner, hvilket forbedrer systemets skalerbarhed og ydeevne yderligere.
En klient kan normalt ikke fortælle, om den er forbundet direkte til slutserveren eller en mellemliggende server. Mellemservere kan forbedre systemets skalerbarhed ved at implementere belastningsbalancering og delt cache. De kan også styrke sikkerhedspolitikker.
Servere kan midlertidigt udvide eller ændre en klients funktionalitet ved at uploade eksekverbar kode til den. For eksempel ved Java-applets eller JavaScript- scripts . Dette hjælper med at forenkle kunder ved at reducere antallet af funktioner, de har brug for at implementere som standard og forbedrer systemets skalerbarhed. På den anden side reducerer det også synligheden af ressourceorganisationen. Derfor udgør det en valgfri begrænsning i en REST-arkitektur.
Den ensartede interface-begrænsning er grundlæggende i designet af ethvert REST-system. Det forenkler og afkobler arkitekturen, så hver komponent kan udvikle sig uafhængigt. De fire begrænsninger for den ensartede grænseflade er som følger.
Identificering af ressourcer i forespørgsler Hver ressource identificeres i anmodninger, for eksempel af en URI i tilfælde af webbaserede REST-systemer. Selve ressourcerne adskiller sig konceptuelt fra de repræsentationer, der returneres til klienten. For eksempel kan serveren sende data fra sin database i HTML , XML eller JSON , som er forskellige repræsentationer af den interne repræsentation af ressourcen. Manipulation af ressourcer efter repræsentationer Hver repræsentation af en ressource giver tilstrækkelig information til, at klienten kan ændre eller slette ressourcen. Selvbeskrivende meddelelser Hver meddelelse indeholder tilstrækkelig information til at vide, hvordan den skal fortolkes. For eksempel kan den tolk, der skal påberåbes, beskrives af en type medier . Hypermedia som applikationsstatusmotor ( HATEOAS ) Efter at have fået adgang til en indledende URI af applikationen - analogt med mennesker, der har adgang til en hjemmesides hjemmeside - skal klienten være i stand til dynamisk at bruge de hyperlinks, der leveres af serveren, til at finde de andre mulige handlinger og de ressourcer, den har brug for for at fortsætte browsing. Det er ikke nødvendigt for klienten at hårdkode disse oplysninger vedrørende applikationens struktur eller dynamik.De arkitektoniske begrænsninger i REST giver de systemer, der respekterer dem, følgende arkitektoniske egenskaber:
RESTs klient - serveradskillelse af bekymringer forenkler implementering af komponenter, reducerer kompleksiteten af connector-semantik, forbedrer effektiviteten af performance tuning og øger skalerbarheden af rene serverkomponenter. Lagdelte systembegrænsninger tillader, at mellemled - proxies, gateways og firewalls - introduceres på forskellige punkter i kommunikationen uden at ændre grænsefladerne mellem komponenter, hvilket giver dem mulighed for at hjælpe med kommunikationsoversættelse eller forbedre ydeevnen via storskala, delt caching. REST muliggør mellembehandling ved at begrænse meddelelser til at være selvbeskrivende: interaktion er statsløs mellem anmodninger, standardmetoder og medietyper bruges til at indikere semantik og udveksle information, og svar indikerer eksplicit cacheabilitet.
“ Adskillelsen af klient - server bekymringer forenkler komponentimplementering, reducerer kompleksiteten af connector semantik, forbedrer effektiviteten til tuning af ydelse og øger skalerbarheden af rene serverkomponenter. Den lagdelte arkitekturbegrænsning gør det muligt for mellemmænd - proxyservere, gateways og firewalls - at blive introduceret på forskellige niveauer i kommunikationen uden at ændre grænsefladerne mellem komponenterne, hvilket giver dem mulighed for at gribe ind i oversættelsen af kommunikationen eller forbedre ydelsen gennem storskala caching systemer. REST tillader mellembehandling ved at tvinge selvbeskrivende meddelelser: interaktionen er statsløs mellem anmodninger, standardmetoder og medietyper bruges til at indikere semantik og udveksle information, og svar angiver eksplicit muligheden for caching. "
Den API REST-baserede HTTP er defineret ved:
Følgende tabel viser, hvordan HTTP-metoder typisk bruges i en REST API:
URI | FÅ | STOLPE | SÆTTE | LAPPE | SLET |
---|---|---|---|---|---|
Ressourceindsamling, såsom http://api.exemple.com/collection/ | Henter URI'erne for ressourcemedlemmerne til indsamlingsressourcen i responsorganet. | Opretter en medlemsressource i indsamlingsressourcen ved hjælp af instruktionerne i anmodningsorganet. URI for den oprettede medlemsressource tildeles automatisk og returneres i feltet Placeringsoverskrift i svaret. | Erstatter alle repræsentationer af medlemsressourcer i indsamlingsressourcen med repræsentationen i anmodningsorganet eller opretter indsamlingsressourcen, hvis den ikke findes. | Opdaterer alle repræsentationer af medlemsressourcer for indsamlingsressourcen ved hjælp af instruktionerne i anmodningsorganet eller opretter eventuelt indsamlingsressourcen, hvis den ikke findes. | Fjerner alle repræsentationer af medlemsressourcer fra indsamlingsressourcen. |
Medlemsressource, såsom http://api.exemple.com/collection/item3 | Henter en repræsentation af medlemsressourcen i responsorganet. | Opretter en medlemsressource i medlemsressourcen ved hjælp af instruktionerne i anmodningsorganet. URI for den oprettede medlemsressource tildeles automatisk og returneres i feltet Placeringsoverskrift i svaret. | Erstatter alle repræsentationer af medlemsressourcen eller opretter medlemsressourcen, hvis den ikke findes, med repræsentationen i anmodningen. | Opdaterer alle repræsentationer af medlemsressourcen eller opretter eventuelt medlemsressourcen, hvis den ikke findes ved hjælp af instruktionerne i anmodningsorganet. | Fjerner alle repræsentationer af medlemsressourcen. |
GET-metoden er sikker, det vil sige, at anvendelse af den på en ressource ikke resulterer i en ændring af ressourcens tilstand (skrivebeskyttet semantik). Metoderne GET, PUT og SLET er idempotente , dvs. at anvende dem flere gange på en ressource resulterer i den samme ændring i ressourcens tilstand som at anvende dem en gang, selvom svaret kan være forskelligt. GET- og POST-metoderne er cacheable , dvs. lagring af svar på disse anmodninger om fremtidig genbrug er tilladt.
I modsætning til SOAP- orienterede webtjenester er der ingen officiel standard for REST API'er, fordi REST er en arkitektur, mens SOAP er en protokol. REST er ikke en standard i sig selv, men implementeringer, der følger denne arkitektur, bruger standarder som HTTP , URI , JSON og XML .