Oversigt over REST. Del 2: Kommunikation mellem en klient og server

Oversigt over REST. Del 1: Hvad er REST? I denne del vil vi dykke dybt ned i, hvordan kommunikationen foregår mellem en klient og server. Undervejs vil vi afdække nye termer og forklare dem. For at sikre, at alt er klart, analyserer vi klient-server-kommunikation ved hjælp af en RESTful-applikation som eksempel. Antag, at vi udvikler en webapplikation, der gemmer oplysninger om kunder og deres ordrer. Med andre ord er vores system i stand til at udføre operationer på bestemte enheder: oprette, redigere og slette dem og vise oplysninger om dem. Disse enheder vil være:

• kunder (kunder)
• ordrer (kundeordrer)
• varer (produkter)

I en RESTful-arkitektur sender klienter anmodninger til en server for at hente eller ændre data, og derefter sender servere klienter svar på deres anmodninger.

Forespørgsler

Kundeanmodninger foretages næsten altid ved hjælp af HTTP-protokollen. Generelt består HTTP-anmodninger af flere komponenter:

• HTTP metode
• header
• URI
• anmodningsorgan

Nedenfor vil vi overveje hver komponent mere detaljeret.

URI'er og ressourcer

De data, som klienter modtager eller ændrer gennem anmodninger, kaldes ressourcer. Klient-server-kommunikation handler om at manipulere ressourcer. I REST er ressourcer alt, hvad du kan give et navn til. På en måde er de som klasser i Java. I Java kan vi oprette en klasse til hvad som helst. Så i REST kan en ressource være hvad som helst: en bruger, et dokument, en rapport, en ordre. Det kan enten være en abstraktion af en enhed eller noget specifikt, for eksempel et billede, en video, en animation eller en PDF-fil. I vores eksempel har vi 3 ressourcer:

• kunder (kunder)
• ordrer (kundeordrer)
• varer (produkter)

Klienter sender anmodninger til ressourcelokationer kendt som slutpunkter. Kort sagt er et slutpunkt som en adresse på netværket. Dykker vi dybere, kan vi sige, at et endepunkt er en URI, altså en sekvens af tegn, der identificerer en abstrakt eller fysisk ressource. Ensartet ressourceidentifikator (URI) Nogle gange kaldes et slutpunkt, eller URI, en sti, hvilket betyder stien til en ressource. I forbindelse med denne artikel vil vi bruge udtrykket URI. Hver specifik ressource skal have en unik URI. Serverudvikleren er ansvarlig for at sikre, at hver ressource altid har sin egen URI. I vores eksempel er vi udviklerne, så vi vil gøre det på den måde, vi ved hvordan. Ligesom det ofte er sædvanligt at tildele numeriske identifikatorer som de primære nøgler i en relationsdatabase, har hver ressource også sit eget ID i REST. Ressource-id'et i REST matcher ofte ID'et for posten i databasen, der gemmer information om ressourcen. REST URI'er starter sædvanligvis med flertalsformen af ​​et substantiv, der beskriver en ressource. For eksempel, "

• /customers — URI for alle tilgængelige kunder
• /customers/23 — URI for en specifik kunde, dvs. kunden med ID=23
• /customers/4 — URI for en specifik kunde, dvs. kunden med ID=4.

Men det er ikke alt. Vi kan udvide URI'en ved at tilføje ordrer:

• /customers/4/orders — URI for alle ordrer foretaget af kunde nr. 4
• /customers/1/orders/12 — URI af ordre nr. 12 lavet af kunde nr. 1.

Hvis vi fortsætter udvidelsen ved at tilføje flere produkter, får vi:

• /customers/1/orders/12/items — URI på listen over alle produkter i ordre nr. 12 lavet af kunde nr. 1.

Når vi tilføjer niveauer af nesting, er det vigtige at gøre URI'erne intuitive.

HTTP metode

HTTP-metoden er en sekvens af alle tegn (undtagen kontroltegn og afgrænsningstegn), som angiver hovedhandlingen, der udføres på ressourcen. Der er flere almindelige HTTP-metoder. Vi vil liste dem, der bruges oftest i RESTful-tjenester:

• GET — Få information om en bestemt ressource (gennem dens ID) eller om en samling af ressourcer
• POST — Opret en ny ressource
• PUT — Skift en ressource (via dens ID)
• SLET — Slet en ressource (via dens ID)

Overskrifter

Forespørgsler, såvel som svar, indeholder HTTP-headere. De formidler yderligere oplysninger om anmodningen (eller svaret). Overskrifter er nøgleværdi-par. Du kan se listen over de mest almindelige overskrifter på Wikipedia . Hvad angår REST, sender klienter ofte en "Accepter"-header i anmodninger til serveren. Denne header er nødvendig for at fortælle serveren, hvilket format klienten forventer at modtage et svar i. Forskellige formater er angivet i en liste over MIME-typer. MIME (Multipurpose Internet Mail Extensions) er en specifikation til kodning af information og formatering af beskeder, så de kan sendes over internettet. Hver MIME-type består af to dele adskilt af en skråstreg - en type og undertype. Eksempler på MIME-typer for forskellige filtyper:

• tekst — text/plain, text/css, text/html
• billede — billede/png, billede/jpeg, billede/gif
• lyd — audio/wav, audio/mpeg
• video — video/mp4, video/ogg
• application — application/json, application/pdf, application/xml, application/octet-stream

For eksempel kan en anmodning have en overskrift som denne:

Accept:application/json

Denne header fortæller serveren, at klienten forventer at modtage et svar i JSON-format.

Anmodningsorgan

Dette er den besked, som klienten sender til serveren. Hvorvidt anmodningen har en krop eller ej, afhænger af typen af ​​HTTP-anmodning. For eksempel indeholder GET- og SLET-anmodninger generelt ikke nogen anmodningstekst. Men PUT- og POST-anmodninger kan - det afhænger bare af formålet med anmodningen. Når alt kommer til alt, for at modtage og/eller slette data ved hjælp af et ID (som sendes i URL'en), behøver du ikke at sende yderligere data til serveren. Men for at oprette en ny ressource (gennem en POST-anmodning), skal du sende ressourcen. Det samme gælder for ændring af en eksisterende ressource. I REST sendes anmodningsteksten oftest i XML- eller JSON-format. JSON-formatet er mest almindeligt. Antag, at vi vil sende en anmodning til serveren for at oprette en ny ressource. Hvis du ikke har glemt, vi betragtede eksemplet på en applikation, der administrerer kundeordrer. Lad os sige, at vi vil oprette en ny kunde. I vores tilfælde gemmer vi følgende kundeoplysninger: Navn, e-mail, telefonnummer. Så brødteksten i anmodningen kunne være følgende JSON:

{
  "name" : "Amigo",
  "email" : "amigo@jr.com",
  "phone" : "+1 (222) 333-4444"
}

Sammensætte anmodninger

Så vi har undersøgt, hvad der kan være i en kundeanmodning. Vi vil nu give nogle eksempler på anmodninger sammen med beskrivelser

Svar

Lad os sige et par ord om serversvar. Et svar består normalt af følgende dele:

• svarkode
• overskrifter
• svar organ

Generelt er svaroverskrifter ikke meget forskellige fra anmodningsoverskrifter. Derudover bruges nogle overskrifter i både svar og anmodninger. Jeg tror også, at alt er klart med hensyn til anmodningsorganet. Organet returnerer ofte oplysninger, som klienten har anmodet om. Oplysninger, der returneres som svar på GET-anmodninger, kan også være i JSON-format. Men den sidste del er lidt mere interessant.

HTTP-svarkoder

Lad os overveje HTTP-svarkoder mere detaljeret. En HTTP-statuskode er en del af den første linje i et serversvar på anmodninger foretaget via HTTP-protokollen. Det er et heltal bestående af tre decimaltal. Det første ciffer angiver klassen for svarstatuskoden. Svarkoden efterfølges normalt af en forklarende sætning på engelsk, adskilt af et mellemrum. Denne sætning er en menneskelig-læselig årsag til svaret. Eksempler:

• 201 Oprettet
• 401 Uautoriseret
• 507 Utilstrækkelig opbevaring

Svarkoden fortæller klienten resultatet af anmodningen og giver den mulighed for at bestemme, hvilke handlinger der skal tages næste gang. Svarkoder er opdelt i flere klasser eller grupper:

• 1XX — Oplysninger
• 2XX — Disse koder angiver, at kundens anmodning blev modtaget og behandlet
• 3XX — Disse koder informerer klienten om, at en yderligere anmodning, normalt til en anden URI, skal foretages for at fuldføre operationen.
• 4XX — Klientfejl. Sådanne koder kan skyldes en forkert sammensat anmodning. Et andet eksempel er den velkendte "404 Not Found"-kode, som kan forekomme, når en klient anmoder om en ikke-eksisterende ressource
• 5XX — Serverfejl. Disse koder returneres til klienten, hvis serveren er ansvarlig for fejl i operationen

Oversigt over REST. Del 3: Opbygning af en RESTful service på Spring Boot