8.1 Ekstern API-tilnærming

Alle programmerere gjør den samme feilen når de bygger en klient-server-arkitektur. De begynner å behandle forespørsler til serveren som metodekall .

Du vil starte rapportgenereringsprosessen på serveren, hvorfor ikke sende den en forespørsel som:

http://server.com/startDocumentGeneration?params

Og hvordan laste ned rapporten etter at den er fullført? For å gjøre dette, vil vi skrive en annen metode:

http://server.com/getDocument

Serveren i HttpSessionlagrer informasjon om dokumentet vårt, og så snart dokumentet er generert vil serveren gi det tilbake.

Flott tilnærming. Eller ikke?

Tilnærmingen er virkelig forferdelig. Saken er at serveren må huske dokumentnummeret. Med andre ord, for å kunne behandle nye metodekall på riktig måte, må serveren huske resultatene av å kalle tidligere metoder.

Java webinar

På nettet er dette et stort problem. Internett kan forsvinne, nettleseren kan lukkes. Siden kan lastes inn på nytt eller ved et uhell klikkes på en lenke, og så videre. Og serveren vil fortsette å lagre megabyte med data fra tidligere brukerforespørsler ...

For komfortabelt arbeid med serveren kan du ikke forvente at du alltid vil ha dataene fra tidligere forespørsler til serveren for hånden.

Hvordan kaller jeg metodene til serveren? Det riktige svaret ville vært forferdelig: nei!

8.2 REST-tilnærming

Programmererne gikk tilbake til det grunnleggende og husket at forespørselen opprinnelig inneholdt banen til filen på serveren:

http://server.com/path?params

Og vi bestemte oss for å bruke denne tilnærmingen maksimalt.

Nå betraktes serveren som et datalager som er synlig utad i form av et tre .

Hvis du ønsker å få en liste over alle brukere, ring spørringen:

http://server.com/users

Hvis du ønsker å få data om bruker 113, kjør spørringen:

http://server.com/users/113

Og så videre, alt på samme måte.

Nok en gang blir serveren sett på som et datalager som er synlig utad i form av et tre.

Data kan mottas - GET- forespørsler , modifisert - POST -forespørsel og slettet - DELETE -forespørsel .

8.3 Ingen stat

REST-protokollen for interaksjon mellom klienten og serveren krever følgende betingelse: i perioden mellom forespørsler fra klienten lagres ingen informasjon om klientens tilstand på serveren.

Alle forespørsler fra klienten må utformes på en slik måte at serveren mottar all informasjonen den trenger for å oppfylle forespørslen hver gang . Sesjonstilstanden lagres på klientsiden.

Under behandlingen av klientforespørsler anses klienten å være i en overgangstilstand. Hver enkelt applikasjonstilstand er representert av lenker som kan påkalles neste gang klienten treffer.

8.4 Grensesnittuniformitet

Alle stier som brukes til å hente objekter fra serveren er standardiserte. Dette er veldig praktisk, spesielt hvis du får data fra andre REST-servere.

Alle objektgrensesnitt må oppfylle tre betingelser:

Ressursidentifikasjon

Alle ressurser identifiseres i forespørsler ved hjelp av en URI. Ressursene inne i serveren er atskilt fra visningene som returneres til klientene. For eksempel kan en server sende data fra en database som HTML, XML eller JSON, ingen av disse er en lagringstype på serveren.

Manipulere ressurser gjennom en visning

Hvis klienten lagrer en representasjon av ressursen, inkludert metadata, har den nok informasjon til å endre eller slette ressursen på serveren.

"Selvbeskrivende" meldinger

Hver melding inneholder nok informasjon til å forstå hvordan den skal behandles. For eksempel, hvis du trenger informasjon om brukeren, vil serveren returnere deg et JSON-objekt, hvor det vil være navn, adressefelt.

Det bør ikke være en situasjon der klienten trenger å vite at det første tallet i svaret er alderen, og det andre er fødselsdatoen.

8.5 Buffer

REST-tilnærmingen forutsetter at dataforespørsler gjøres via HTTP-protokollen. Derfor oppnås objekter ved å ringe en GET-forespørsel. Dette betyr at de, som alle ressurser mottatt via en GET-forespørsel, er underlagt alle reglene for bufring av HTTP-ressurser.

Det vil si at data mottatt via REST API bufres på samme måte som eventuelle statiske ressurser på webservere. Skjønnhet :)