Översikt över REST. Del 2: Kommunikation mellan en klient och server

Översikt över REST. Del 1: Vad är REST? I den här delen kommer vi att djupdyka hur kommunikationen sker mellan en klient och server. Längs vägen kommer vi att avslöja nya termer och förklara dem. För att säkerställa att allt är tydligt kommer vi att analysera klient-serverkommunikation med hjälp av en RESTful-applikation som exempel. Anta att vi utvecklar en webbapplikation som lagrar information om kunder och deras beställningar. Med andra ord kan vårt system utföra operationer på vissa enheter: skapa, redigera och ta bort dem och visa information om dem. Dessa enheter kommer att vara:

• kunder (kunder)
• order (kundordrar)
• varor (produkter)

I en RESTful-arkitektur skickar klienter förfrågningar till en server för att hämta eller ändra data, och sedan skickar servrar klienternas svar på deras förfrågningar.

Förfrågningar

Klientförfrågningar görs nästan alltid med hjälp av HTTP-protokollet. I allmänhet består HTTP-förfrågningar av flera komponenter:

• HTTP-metod
• rubrik
• URI
• begäran organ

Nedan kommer vi att överväga varje komponent mer i detalj.

URI:er och resurser

Den data som klienter tar emot eller ändrar genom förfrågningar kallas resurser. Kommunikation mellan klient och server handlar om att manipulera resurser. I REST är resurser allt du kan ge ett namn till. På sätt och vis är de som klasser i Java. I Java kan vi skapa en klass för vad som helst. Så i REST kan en resurs vara vad som helst: en användare, ett dokument, en rapport, en order. Det kan antingen vara en abstraktion av någon enhet eller något specifikt, till exempel en bild, video, animation eller PDF-fil. I vårt exempel har vi tre resurser:

• kunder (kunder)
• order (kundordrar)
• varor (produkter)

Klienter skickar förfrågningar till resursplatser som kallas slutpunkter. Enkelt uttryckt är en slutpunkt som en adress i nätverket. Om vi ​​dyker djupare kan vi säga att en slutpunkt är en URI, dvs en sekvens av tecken som identifierar en abstrakt eller fysisk resurs. Uniform resursidentifierare (URI) Ibland kallas en slutpunkt, eller URI, en sökväg, vilket betyder sökvägen till en resurs. I den här artikeln kommer vi att använda termen URI. Varje specifik resurs måste ha en unik URI. Serverutvecklaren ansvarar för att varje resurs alltid har sin egen URI. I vårt exempel är vi utvecklarna, så vi kommer att göra det på det sätt vi vet hur. Precis som det ofta är vanligt att tilldela numeriska identifierare som primärnycklar i en relationsdatabas, har varje resurs också sitt eget ID i REST. Resurs-ID:t i REST matchar ofta ID:t för posten i databasen som lagrar information om resursen. REST URI börjar vanligtvis med pluralformen av ett substantiv som beskriver någon resurs. Till exempel, "

• /customers — URI för alla tillgängliga kunder
• /customers/23 — URI för en specifik kund, dvs kunden med ID=23
• /customers/4 — URI för en specifik kund, dvs kunden med ID=4.

Men det är inte allt. Vi kan utöka URI:n genom att lägga till beställningar:

• /customers/4/orders — URI för alla beställningar gjorda av kund nr 4
• /customers/1/orders/12 — URI för order nr 12 gjord av kund nr 1.

Om vi ​​fortsätter expansionen genom att lägga till fler produkter får vi:

• /customers/1/orders/12/items — URI för listan över alla produkter i order nr 12 gjord av kund nr 1.

När vi lägger till nivåer av kapsling är det viktiga att göra URI:erna intuitiva.

HTTP-metod

HTTP-metoden är en sekvens av alla tecken (förutom kontrolltecken och avgränsare), som indikerar huvudoperationen som utförs på resursen. Det finns flera vanliga HTTP-metoder. Vi kommer att lista de som används oftast i RESTful-tjänster:

• GET — Få information om en viss resurs (genom dess ID) eller om en samling resurser
• POST — Skapa en ny resurs
• PUT — Ändra en resurs (genom dess ID)
• DELETE – Ta bort en resurs (via dess ID)

Rubriker

Förfrågningar, såväl som svar, innehåller HTTP-rubriker. De förmedlar ytterligare information om begäran (eller svaret). Rubriker är nyckel-värdepar. Du kan se listan över de vanligaste rubrikerna på Wikipedia . När det gäller REST skickar klienter ofta ett "Acceptera"-huvud i förfrågningar till servern. Denna rubrik behövs för att tala om för servern i vilket format klienten förväntar sig att få ett svar. Olika format anges i en lista över MIME-typer. MIME (Multipurpose Internet Mail Extensions) är en specifikation för kodning av information och formatering av meddelanden så att de kan skickas över Internet. Varje MIME-typ består av två delar separerade med ett snedstreck - en typ och en undertyp. Exempel på MIME-typer för olika typer av filer:

• text — text/plain, text/css, text/html
• bild — bild/png, bild/jpeg, bild/gif
• ljud — ljud/wav, ljud/mpeg
• video — video/mp4, video/ogg
• application — application/json, application/pdf, application/xml, application/octet-stream

Till exempel kan en begäran ha en rubrik så här:

Accept:application/json

Den här rubriken talar om för servern att klienten förväntar sig att få ett svar i JSON-format.

Begäran kropp

Detta är meddelandet som skickas av klienten till servern. Huruvida begäran har en text eller inte beror på typen av HTTP-begäran. Till exempel innehåller GET- och DELETE-förfrågningar i allmänhet inte någon begärandekropp. Men PUT- och POST-förfrågningar kan - det beror bara på syftet med begäran. När allt kommer omkring, för att ta emot och/eller radera data med hjälp av ett ID (som skickas i URL) behöver du inte skicka ytterligare data till servern. Men för att skapa en ny resurs (genom en POST-förfrågan) måste du skicka resursen. Detsamma gäller för att modifiera en befintlig resurs. I REST skickas förfrågningstexten oftast i XML- eller JSON-format. JSON-formatet är vanligast. Anta att vi vill skicka en begäran till servern för att skapa en ny resurs. Om du inte har glömt, vi betraktade exemplet på en applikation som hanterar kundorder. Låt oss säga att vi vill skapa en ny kund. I vårt fall lagrar vi följande kunduppgifter: Namn, e-post, telefonnummer. Då kan brödtexten i begäran vara följande JSON:

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

Sätt ihop förfrågningar

Så vi har undersökt vad som kan finnas i en kundförfrågan. Vi kommer nu att ge några exempel på förfrågningar tillsammans med beskrivningar

Svar

Låt oss säga några ord om serversvar. Ett svar består vanligtvis av följande delar:

• svarskod
• rubriker
• svarskropp

I allmänhet skiljer sig svarsrubriker inte mycket från förfrågningsrubriker. Dessutom används vissa rubriker i både svar och förfrågningar. Jag tror att allt också är klart när det gäller begärandeinstansen. Organet returnerar ofta information som kunden begärt. Information som returneras som svar på GET-förfrågningar kan också vara i JSON-format. Men den sista delen är lite mer intressant.

HTTP-svarskoder

Låt oss överväga HTTP-svarskoder mer i detalj. En HTTP-statuskod är en del av den första raden i ett serversvar på förfrågningar som görs via HTTP-protokollet. Det är ett heltal som består av tre decimalsiffror. Den första siffran anger klassen för svarsstatuskoden. Svarskoden följs vanligtvis av en förklarande fras på engelska, åtskilda av ett mellanslag. Denna fras är en läsbar orsak till svaret. Exempel:

• 201 Skapad
• 401 Obehörig
• 507 Otillräcklig lagring

Svarskoden berättar för klienten resultatet av begäran och låter den bestämma vilka åtgärder som ska vidtas härnäst. Svarskoder är indelade i flera klasser eller grupper:

• 1XX — Information
• 2XX — Dessa koder indikerar att kundens begäran har tagits emot och behandlats
• 3XX — Dessa koder informerar kunden om att en ytterligare begäran, vanligtvis till en annan URI, måste göras för att kunna slutföra operationen.
• 4XX — Klientfel. Sådana koder kan vara resultatet av en felaktigt sammansatt begäran. Ett annat exempel är den välkända "404 Not Found"-koden, som kan uppstå när en klient begär en icke-existerande resurs
• 5XX — Serverfel. Dessa koder returneras till klienten om servern är ansvarig för fel i operationen

Översikt över REST. Del 3: Bygga en RESTful tjänst på Spring Boot