8.1 Fjern API-tilgang

Alle programmører begår den samme fejl, når de bygger en klient-server-arkitektur. De begynder at behandle anmodninger til serveren som metodekald .

Du vil starte rapportgenereringsprocessen på serveren, hvorfor ikke sende den en anmodning som:

http://server.com/startDocumentGeneration?params

Og hvordan downloader man rapporten, når den er færdig? For at gøre dette vil vi skrive en anden metode:

http://server.com/getDocument

Serveren i HttpSessiongemmer information om vores dokument, og så snart dokumentet er genereret, vil serveren give det tilbage.

Fantastisk tilgang. Eller ikke?

Tilgangen er virkelig forfærdelig. Sagen er, at serveren skal huske dokumentnummeret. Med andre ord, for at kunne behandle nye metodekald korrekt, skal serveren huske resultaterne af at kalde tidligere metoder.

På nettet er dette et stort problem. Internettet kan forsvinde, browseren kan lukke. Siden kan genindlæses eller ved et uheld klikkes på et link, og så videre. Og serveren vil fortsætte med at gemme megabyte data fra tidligere brugeranmodninger ...

For behageligt arbejde med serveren kan du ikke forvente, at du altid har data fra tidligere anmodninger til serveren ved hånden.

Hvordan kalder man så serverens metoder? Det rigtige svar ville være forfærdeligt: ​​nej!

8.2 REST tilgang

Programmørerne gik tilbage til det grundlæggende og huskede, at anmodningen oprindeligt indeholdt stien til filen på serveren:

http://server.com/path?params

Og vi besluttede at bruge denne tilgang til det maksimale.

Nu betragtes serveren som et lager af data , der er synligt udadtil i form af et træ .

Hvis du vil have en liste over alle brugere, skal du ringe til forespørgslen:

http://server.com/users

Hvis du vil have data på bruger 113, skal du køre forespørgslen:

http://server.com/users/113

Og så videre, alt sammen i samme ånd.

Endnu en gang ses serveren som et lager af data, der er synligt udadtil i form af et træ.

Data kan modtages - GET- anmodninger , modificeret - POST- anmodning og slettet - DELETE -anmodning .

8.3 Ingen stat

REST-protokollen for interaktion mellem klienten og serveren kræver følgende betingelse: i perioden mellem anmodninger fra klienten gemmes ingen information om klientens tilstand på serveren.

Alle anmodninger fra klienten skal udformes på en sådan måde, at serveren modtager al den information, den behøver for at opfylde anmodningen hver gang . Sessionstilstanden gemmes på klientsiden.

Under behandlingen af ​​klientanmodninger anses klienten for at være i en overgangstilstand. Hver enkelt applikationstilstand er repræsenteret af links, der kan aktiveres, næste gang klienten rammer.

8.4 Interfaceens ensartethed

Alle stier, der bruges til at hente objekter fra serveren, er standardiserede. Dette er meget praktisk, især hvis du får data fra andre REST-servere.

Alle objektgrænseflader skal overholde tre betingelser:

Ressourceidentifikation

Alle ressourcer identificeres i anmodninger ved hjælp af en URI. Ressourcerne inde i serveren er adskilt fra de visninger, der returneres til klienterne. For eksempel kan en server sende data fra en database som HTML, XML eller JSON, hvoraf ingen af ​​dem er en lagertype på serveren.

Manipulering af ressourcer gennem en visning

Hvis klienten gemmer en repræsentation af ressourcen, inklusive metadata, så har den nok information til at ændre eller slette ressourcen på serveren.

"Selv-beskrivende" beskeder

Hver besked indeholder nok information til at forstå, hvordan den skal behandles. For eksempel, hvis du har brug for information om brugeren, så vil serveren returnere dig et JSON objekt, hvor der vil være navn, adresse felter.

Der bør ikke være en situation, hvor klienten skal vide, at det første tal i svaret er alderen, og det andet er fødselsdatoen.

8.5 Caching

REST-tilgangen antager, at dataanmodninger foretages via HTTP-protokollen. Derfor opnås objekter ved at kalde en GET-anmodning. Det betyder, at de, ligesom alle ressourcer modtaget via en GET-anmodning, er underlagt alle reglerne for cachelagring af HTTP-ressourcer.

Det vil sige, at data modtaget via REST API cachelagres på samme måde som eventuelle statiske ressourcer på webservere. Skønhed :)