Introduktion till REST

8.1 Remote API-metoden

Alla programmerare gör samma misstag när de bygger en klient-server-arkitektur. De börjar behandla förfrågningar till servern som metodanrop .

Du vill starta rapportgenereringsprocessen på servern, varför inte skicka den en begäran som:

http://server.com/startDocumentGeneration?params

Och hur laddar man ner rapporten efter att den är klar? För att göra detta kommer vi att skriva en annan metod:

http://server.com/getDocument

Servern i HttpSessionlagrar information om vårt dokument, och så fort dokumentet är genererat kommer servern att ge tillbaka det.

Bra tillvägagångssätt. Eller inte?

Tillvägagångssättet är verkligen hemskt. Grejen är att servern måste komma ihåg dokumentnumret. Med andra ord, för att korrekt bearbeta nya metodanrop måste servern komma ihåg resultatet av anropet av tidigare metoder.

På webben är detta ett stort problem. Internet kan försvinna, webbläsaren kan stängas. Sidan kan laddas om eller av misstag klickas på en länk, och så vidare. Och servern kommer att fortsätta att lagra megabyte data från tidigare användarförfrågningar ...

För bekvämt arbete med servern kan du inte förvänta dig att du alltid har data från tidigare förfrågningar till servern till hands.

Hur anropar man då serverns metoder? Rätt svar skulle vara hemskt: nej!

8.2 REST-tillvägagångssätt

Programmerarna gick tillbaka till grunderna och kom ihåg att förfrågan från början innehöll sökvägen till filen på servern:

http://server.com/path?params

Och vi bestämde oss för att använda detta tillvägagångssätt maximalt.

Nu betraktas servern som ett datalager som är synligt utåt i form av ett träd .

Om du vill få en lista över alla användare, ring frågan:

http://server.com/users

Om du vill få data om användare 113, kör frågan:

http://server.com/users/113

Och så vidare, allt i samma veva.

Återigen ses servern som ett arkiv av data som är synligt utåt i form av ett träd.

Data kan tas emot - GET- förfrågningar , modifierade - POST -begäran och raderade - DELETE -begäran .

8.3 Ingen stat

REST-protokollet för interaktion mellan klienten och servern kräver följande villkor: under perioden mellan förfrågningar från klienten lagras ingen information om klientens tillstånd på servern.

Alla förfrågningar från klienten måste utformas på ett sådant sätt att servern får all information den behöver för att uppfylla begäran varje gång . Sessionstillståndet sparas på klientsidan.

Under behandlingen av klientförfrågningar anses klienten vara i ett övergångstillstånd. Varje enskilt applikationstillstånd representeras av länkar som kan anropas nästa gång klienten träffar.

8.4 Enhetlighet i gränssnittet

Alla sökvägar som används för att hämta objekt från servern är standardiserade. Detta är mycket bekvämt, speciellt om du får data från andra REST-servrar.

Alla objektgränssnitt måste uppfylla tre villkor:

Resursidentifiering

Alla resurser identifieras i förfrågningar med hjälp av en URI. Resurserna inuti servern är separata från vyerna som returneras till klienterna. Till exempel kan en server skicka data från en databas som HTML, XML eller JSON, varken är en lagringstyp inom servern.

Manipulera resurser genom en vy

Om klienten lagrar en representation av resursen, inklusive metadata, har den tillräckligt med information för att ändra eller ta bort resursen på servern.

"Självbeskrivande" meddelanden

Varje meddelande innehåller tillräckligt med information för att förstå hur det ska behandlas. Till exempel, om du behöver information om användaren, kommer servern att returnera ett JSON-objekt till dig, där det kommer att finnas namn, adressfält.

Det bör inte finnas en situation där klienten behöver veta att den första siffran i svaret är åldern och den andra är födelsedatumet.

8.5 Cachning

REST-metoden förutsätter att dataförfrågningar görs via HTTP-protokollet. Därför erhålls objekt genom att anropa en GET-förfrågan. Detta innebär att de, liksom alla resurser som tas emot via en GET-begäran, omfattas av alla regler för cachelagring av HTTP-resurser.

Det vill säga att data som tas emot via REST API cachelagras på samma sätt som alla statiska resurser på webbservrar. Skönhet :)