Introducere în REST

8.1 Abordare API de la distanță

Toți programatorii fac aceeași greșeală atunci când construiesc o arhitectură client-server. Ei încep să trateze cererile către server ca apeluri de metodă .

Doriți să începeți procesul de generare a rapoartelor pe server, de ce să nu îi trimiteți o solicitare de genul:

http://server.com/startDocumentGeneration?params

Și cum să descărcați raportul după ce este finalizat? Pentru a face acest lucru, vom scrie o altă metodă:

http://server.com/getDocument

Serverul în HttpSessionstochează informații despre documentul nostru, iar de îndată ce documentul este generat, serverul îl va returna.

O abordare grozavă. Sau nu?

Abordarea este cu adevărat groaznică. Chestia este că serverul trebuie să-și amintească numărul documentului. Cu alte cuvinte, pentru a procesa corect noile apeluri de metode, serverul trebuie să-și amintească rezultatele apelării metodelor anterioare.

Pe web, aceasta este o mare problemă. Internetul poate dispărea, browserul se poate închide. Pagina poate fi reîncărcată sau se poate face clic accidental pe un link și așa mai departe. Și serverul va continua să stocheze megaocteți de date de la solicitările anterioare ale utilizatorilor...

Pentru a lucra confortabil cu serverul, nu vă puteți aștepta să aveți întotdeauna la îndemână datele solicitărilor anterioare către server.

Cum se apelează apoi metodele serverului? Răspunsul corect ar fi groaznic: în niciun caz!

8.2 Abordarea REST

Programatorii s-au întors la elementele de bază și și-au amintit că inițial cererea conținea calea către fișierul de pe server:

http://server.com/path?params

Și am decis să folosim această abordare la maximum.

Acum serverul este considerat ca un depozit de date care este vizibil în exterior sub forma unui arbore .

Dacă doriți să obțineți o listă cu toți utilizatorii, apelați interogarea:

http://server.com/users

Dacă doriți să obțineți date despre utilizatorul 113, rulați interogarea:

http://server.com/users/113

Și așa mai departe, toate în aceeași ordine de idei.

Încă o dată, serverul este văzut ca un depozit de date care este vizibil în exterior sub forma unui arbore.

Datele pot fi primite - solicitări GET , cerere modificată - cerere POST și cerere ștearsă - cerere DELETE .

8.3 Nicio stare

Protocolul REST de interacțiune dintre client și server necesită următoarea condiție: în perioada dintre solicitările de la client, nu sunt stocate informații despre starea clientului pe server.

Toate cererile de la client trebuie să fie elaborate astfel încât serverul să primească de fiecare dată toate informațiile de care are nevoie pentru a îndeplini cererea . Starea sesiunii este salvată pe partea clientului.

În timpul procesării cererilor clientului, clientul este considerat a fi într-o stare de tranziție. Fiecare stare individuală a aplicației este reprezentată de legături care pot fi invocate data viitoare când clientul accesează.

8.4 Uniformitatea interfeței

Toate căile utilizate pentru a prelua obiecte de pe server sunt standardizate. Acest lucru este foarte convenabil, mai ales dacă obțineți date de la alte servere REST.

Toate interfețele obiect trebuie să respecte trei condiții:

Identificarea resurselor

Toate resursele sunt identificate în cereri folosind un URI. Resursele din interiorul serverului sunt separate de vizualizările care sunt returnate clienților. De exemplu, un server poate trimite date dintr-o bază de date ca HTML, XML sau JSON, niciunul dintre acestea nu este un tip de stocare în cadrul serverului.

Manipularea resurselor printr-o vedere

Dacă clientul stochează o reprezentare a resursei, inclusiv metadate, atunci are suficiente informații pentru a modifica sau șterge resursa de pe server.

Mesaje „autodescriere”.

Fiecare mesaj conține suficiente informații pentru a înțelege cum să-l proceseze. De exemplu, dacă aveți nevoie de informații despre utilizator, atunci serverul vă va returna un obiect JSON, unde vor fi câmpuri de nume, adresă.

Nu ar trebui să existe o situație în care clientul trebuie să știe că primul număr din răspuns este vârsta, iar al doilea este data nașterii.

8.5 Memorarea în cache

Abordarea REST presupune că cererile de date sunt făcute prin protocolul HTTP. Prin urmare, obiectele sunt obținute prin apelarea unei cereri GET. Aceasta înseamnă că ele, ca toate resursele primite printr-o solicitare GET, sunt supuse tuturor regulilor pentru stocarea în cache a resurselor HTTP.

Adică, datele primite prin API-ul REST sunt stocate în cache în același mod ca orice resurse statice de pe serverele web. Frumusete :)