Översikt över REST. Del 1: Vad är REST?

Hej! Idag kommer vi att lära oss om ett ämne som är mycket intressant och, viktigast av allt, efterfrågat på arbetsmarknaden: REST. Vi kommer att dela upp vår översikt av REST i tre delar:

1. I den första delen kommer vi att täcka historien om REST och beskriva de principer som REST bygger på.

2. I det andra kommer vi att överväga hur kommunikation mellan en klient och server sker via HTTP-protokollet.

3. I den tredje kommer vi att skriva en liten RESTful-applikation som vi ska testa med ett program som heter "Postman".

Artikeln är avsedd för läsare som är bekanta med följande termer:

• HTTP
• URL och URI
• JSON och (i mindre utsträckning) XML
• Beroendeinjektion

Del 1. Vad är REST?

REST, som så mycket i IT-världen, är en akronym. Det härrör från "Representational State Transfer" . Detta är en arkitektonisk stil för interaktion mellan komponenter i ett distribuerat system i ett datornätverk. Enkelt uttryckt bestämmer REST stilen för interaktion (utbyte av data) mellan olika komponenter i systemet, som var och en kan vara fysiskt placerad på olika platser. Denna arkitektoniska stil är en konsekvent uppsättning begränsningar som följs när man designar ett distribuerat system. Dessa begränsningar kallas ibland de vägledande principerna för REST. Det är inte många, bara 6. Vi ska prata om dem lite senare.

Historia om REST

Termen REST introducerades av Roy Fielding, en av skaparna av HTTP-protokollet, i sin Ph.D. avhandling med titeln "Architectural Styles and the Design of Network-based Software Architectures" år 2000. Även om termen REST fortfarande kan kallas ung, ligger konceptet som det representerar i själva kärnan av World Wide Web. Vi kommer inte att dyka djupt in i termens historia. Om du vill dyka ner i de primära källorna, ta en titt på Fieldings avhandling .

REST begränsningar och principer

Som nämnts ovan definierar REST hur komponenterna i ett distribuerat system ska interagera med varandra. I allmänhet sker detta genom en begäran-svar-process. Komponenten som skickar begäran kallas klienten och komponenten som bearbetar begäran och skickar ett svar till klienten kallas servern. Förfrågningar och svar skickas oftast via HTTP-protokollet. HTTP står för HyperText Transfer Protocol. Vanligtvis är en server en webbapplikation. Kunden kan vara nästan vad som helst. Till exempel en mobilapp som begär data från en server. Eller en webbläsare som skickar förfrågningar från en webbsida till en server för att ladda ner data. Applikation A kan begära data från applikation B. I detta fall är A en klient med avseende på B, och B är en server med avseende på A. Samtidigt skulle A kunna behandla förfrågningar från B, C, D osv. I detta fall är applikation A både en server och en klient. Allt beror på sammanhanget. En sak är säker: komponenten som skickar förfrågan är klienten. Den komponent som tar emot, bearbetar och svarar på en förfrågan är servern. Dock, inte alla system vars komponenter kommunicerar genom en begäran-svar-process är ett RESTful-system. För att ett system ska betraktas som RESTful måste det uppfylla de sex REST-begränsningarna:

1. Klient-server-arkitektur

Denna begränsning handlar om separation av bekymmer. Det är nödvändigt att separera kraven på klientgränssnittet från kraven på servern som lagrar data. Denna begränsning gör klientkoden mer portabel till andra plattformar, och en förenkling av serversidan förbättrar systemets skalbarhet. Genom att göra en skillnad mellan "klienten" och "servern" kan de utvecklas oberoende av varandra.

2. Statslös

En RESTful arkitektur kräver att följande villkor är uppfyllda. Under tiden mellan förfrågningar får servern inte lagra information om klientens tillstånd och vice versa. Alla förfrågningar från klienten måste vara sammansatta på ett sätt som ger servern all nödvändig information för att fullfölja förfrågan. Således kan både servern och klienten "förstå" alla mottagna meddelanden, utan att förlita sig på tidigare meddelanden.

3. Cachebart

Klienter kan cache serversvar. Dessa måste i sin tur uttryckligen eller implicit betecknas som cachade eller icke-cachade, så att klienter inte får föråldrade eller felaktiga data som svar på efterföljande förfrågningar. Korrekt cachelagring hjälper till att helt eller delvis eliminera vissa klient-server-interaktioner, vilket ytterligare ökar systemets prestanda och skalbarhet.

4. Enhetligt gränssnitt

De grundläggande kraven för en RESTful arkitektur inkluderar ett enhetligt, enhetligt gränssnitt. Klienten måste alltid förstå formatet och adresserna den behöver använda när den skickar en begäran, och servern måste i sin tur också förstå formatet den ska använda när den svarar på klientförfrågningar. Denna konsekventa klient-server-interaktion som beskriver vad, var, i vilken form och hur man skickar data är ett enhetligt gränssnitt.

5. Lager

Med lager menar vi nätverkets hierarkiska struktur. Ibland kan en klient kommunicera direkt med servern, och ibland kommunicerar den bara med en mellannod. Användningen av mellanservrar kan öka skalbarheten tack vare lastbalansering och distribuerad cachning. Låt oss ge ett exempel. Föreställ dig en mobilapp som är populär över hela världen. En integrerad del av appen innebär att ladda bilder. Dess användare uppgår till miljontals, så en enda server kan inte hantera en så tung belastning. Att separera systemet i lager kommer att lösa detta problem. Om klienten begär en bild från en mellannod, så begär den mellanliggande noden bilden från servern som är minst laddad för tillfället och returnerar bilden till klienten. Om cachning tillämpas korrekt på varje nivå i hierarkin,

6. Kod på begäran (valfritt)

Denna begränsning innebär att klienten kan utöka sin funktionalitet genom att ladda ner kod från servern i form av appletar eller skript.

Fördelar med en RESTful arkitektur

Applikationer som uppfyller alla ovannämnda begränsningar har följande fördelar: tillförlitlighet (du behöver inte spara klientens tillstånd, vilket kan gå förlorat)

• prestanda (på grund av användningen av en cache)
• skalbarhet
• transparent kommunikation
• enkla gränssnitt
• portabilitet
• förmåga att enkelt göra ändringar
• förmåga att utvecklas och anpassa sig till nya krav

Översikt över REST. Del 2: Kommunikation mellan en klient och server Översikt över REST. Del 3: Bygga en RESTful tjänst på Spring Boot