REST – Repræsentativ statsoverførsel

REST – Transmission af netværkslag

Først og fremmest skal det siges, at REST bruger HTTP eller HTTPS som protokol på højere niveau.

Fordelen ved at bruge HTTP(S) som grundlag for kommunikation er, at de fleste netværk, selvom de er beskyttet af firewalls etc., kan bruges til HTTP(s) end-to-end. Derudover opfylder HTTP(S) de egenskaber, der kræves for REST.

Som det er normalt med HTTP eller HTTPS, bruges TCP-porte 80 eller 443.

REST – egenskaber og primitiver

Klient/server model
REST fungerer efter klient/server metoden, hvor handlingen altid udløses af klienten. Serveren stiller ressourcer (data, indhold, funktioner) til rådighed. Klienten sender en anmodning om at få adgang til udvalgte ressourcer. Serveren leverer de anmodede data med et svar eller bekræfter den ønskede handling.

Tilstandsløshed
Ved mange klient/server-applikationer tildeles en bestemt status (autorisation, specialopgave, specifikt formål, …) på serversiden, når forbindelsen er etableret, som bibeholdes i forbindelsens varighed. REST behandler indledningsvis alle transmissioner til serveren ens, og kun indholdet af datatransmissionen bestemmer yderligere server-side håndtering eller klassificeringen af ​​anmodningen. En ansøgnings tilstand er derfor i klientens hænder.

Lagdelt system
REST sørger for en klar adskillelse af ansvar. Denne adskillelse gælder især for behandling af kommunikation og viderebehandling af det transporterede indhold.

Dette gør det muligt at anvende proxyer, gateways eller lignende mellemstationer på transmissionsvejen.

Afhængigt af sikkerhedskravet kan der desuden vælges HTTP eller krypteret transmission via HTTPS til kommunikation. Dette gør ingen forskel for den funktionelle håndtering af REST-indholdet.

Adresserbarhed af ressourcer
Alle tilgængelige ressourcer på en server kan tilgås via en unik adresse (URI = Uniform Resource Identifier). URI’en er struktureret som den URL, der bruges til adressering i browseren:

Protokoll://://?&

Anmodningsmetoder
De standardiserede HTTP-kald er tilgængelige for anmodningerne:

• GET
  henter ressourcer fra serveren og bruges kun til læsning
• POST
  opretter nye ressourcer eller ændrer eksisterende
• PUT
  ændrer eksisterende ressourcer
• SLET
  sletter eksisterende ressourcer
• HEAD
  anmoder kun om HTTP-headeren, f.eks. B. at kontrollere tilgængeligheden af ​​den ressource, der skal hentes
• OPTIONS
  henter information om kommunikationsmulighederne

De hentede data kaldes repræsentationer af en eller flere ressourcer. Deraf navnet REST for repræsentativ statsoverførsel.

I sidste ende er repræsentationer ikke andet end et billede af dele af procesdataene. Overdragelsen kan foregå i næsten enhver form, men det skal aftales. JSON, XML eller råtekst er almindelige. Men SVG, MP3 eller andre formater bruges også afhængigt af applikationen. Repræsentationen kan også indeholde hyperlinks til andre ressourcer.

Kunden sender:

http://192.168.1.19/rest/json/iostate/

Og web-termo-hygrobarometeret sender som svar:

{
  "iostate": {
    "sensor": [
      {
        "name": "Temperatur",
        "number": 0,
        "unit": "°C",
        "value": 25.9
      },
      {
        "name": "rel. Feuchte",
        "number": 1,
        "unit": "%",
        "value": 43.2
      },
      {
        "name": "Luftdruck",
        "number": 2,
        "unit": "hPa",
        "value": 994.7
      }
    ]
  }
}

Code on Demand
Med hjemmesider er det almindeligt i dag, f.eks. B. at indlæse eller genindlæse JavaScript. REST giver også mulighed for at genindlæse kildekode, programdele eller funktionsblokke. Dette gør det muligt at udvide eller ændre klientens funktion under kørsel.

Cache
REST giver mulighed for at besvare gentagne anmodninger på klientsiden fra en cache (midlertidig lagring) for at reducere databelastningen på transmissionsstierne. Serveren bruger passende information i HTTP-headeren til at bestemme, om cachen må bruges til den anmodede repræsentation.

Fordele ved REST
Enkel implementering, da HTTP-mekanismer bruges så vidt muligt.

Ulemper ved REST
Request/reply-teknikken tillader kun polling, dvs. målrettet hentning af data, men ingen hændelsesstyret kommunikation. De relevante data skal løbende polles (forespørges) for at detektere ændringer.