Bună! Astăzi vom afla despre un subiect foarte interesant și, cel mai important, foarte solicitat pe piața muncii: REST. Vom împărți prezentarea noastră de ansamblu asupra REST în trei părți:
În prima parte, vom acoperi istoria REST și vom descrie principiile pe care se bazează REST.
În al doilea, vom lua în considerare modul în care se realizează comunicarea dintre un client și un server prin protocolul HTTP.
În al treilea, vom scrie o mică aplicație RESTful pe care o vom testa folosind un program numit „Poștaș”.
Articolul este destinat cititorilor familiarizați cu următorii termeni:
HTTP
URL și URI
JSON și (într-o măsură mai mică) XML
Injecție de dependență
Partea 1. Ce este REST?
REST, ca atât în lumea IT, este un acronim. Este derivat din „Transfer de stat reprezentativ” . Acesta este un stil arhitectural pentru interacțiunea dintre componentele unui sistem distribuit într-o rețea de calculatoare. Mai simplu spus, REST determină stilul de interacțiune (schimb de date) între diferite componente ale sistemului, fiecare dintre acestea putând fi localizată fizic în locuri diferite. Acest stil arhitectural este un set consecvent de constrângeri la care se respectă atunci când se proiectează un sistem distribuit. Aceste constrângeri sunt uneori numite principii directoare ale REST. Nu sunt multe, doar 6. Despre ele vom vorbi puțin mai târziu.
Aplicațiile construite având în vedere principiile REST, adică cele care nu încalcă constrângerile REST, se numesc „RESTful”.
Istoria REST
Termenul REST a fost introdus de Roy Fielding, unul dintre creatorii protocolului HTTP, în doctoratul său. teză intitulată „Stiluri arhitecturale și proiectarea arhitecturilor software bazate pe rețea” în 2000. Deși termenul REST poate fi încă numit tânăr, conceptul pe care îl reprezintă se află chiar în centrul World Wide Web. Nu ne vom scufunda adânc în istoria termenului. Dacă doriți să vă scufundați în sursele primare, aruncați o privire la disertația lui Fielding .
Constrângeri și principii REST
După cum sa menționat mai sus, REST definește modul în care componentele unui sistem distribuit ar trebui să interacționeze între ele. În general, acest lucru se întâmplă printr-un proces cerere-răspuns. Componenta care trimite cererea se numește client , iar componenta care procesează cererea și trimite un răspuns clientului se numește server. Solicitările și răspunsurile sunt trimise cel mai adesea prin protocolul HTTP. HTTP înseamnă HyperText Transfer Protocol. De obicei, un server este o aplicație web. Clientul poate fi aproape orice. De exemplu, o aplicație mobilă care solicită date de la un server. Sau un browser care trimite cereri de pe o pagină web către un server pentru a descărca date. Aplicația A poate solicita date de la Aplicația B. În acest caz, A este un client față de B, iar B este un server față de A. În același timp, A ar putea procesa cereri de la B, C, D etc. În acest caz, aplicația A este atât un server, cât și un client. Totul depinde de context. Un lucru este cert: componenta care trimite cererea este clientul. Componenta care primește, procesează și răspunde la o solicitare este serverul. In orice caz, nu orice sistem ale cărui componente comunică printr-un proces cerere-răspuns este un sistem RESTful. Pentru ca un sistem să fie considerat RESTful, trebuie să respecte cele șase constrângeri REST:
1. Arhitectura client-server
Această constrângere se referă la separarea preocupărilor. Este necesar să se separe cerințele interfeței client de cerințele serverului care stochează datele. Această constrângere face codul client mai portabil pe alte platforme, iar simplificarea părții server îmbunătățește scalabilitatea sistemului. Făcând o distincție între „client” și „server” le permite să fie dezvoltate independent unul de celălalt.
2. Apatrid
O arhitectură RESTful necesită îndeplinirea următoarelor condiții. În perioada dintre solicitări, serverul nu trebuie să stocheze informații despre starea clientului și invers. Toate cererile de la client trebuie să fie compuse într-un mod care să ofere serverului toate informațiile necesare pentru a finaliza cererea. Astfel, atât serverul cât și clientul pot „înțelege” orice mesaj primit, fără a se baza pe mesajele anterioare.
3. Cacheabil
Clienții pot stoca în cache răspunsurile serverului. Acestea, la rândul lor, trebuie să fie desemnate în mod explicit sau implicit ca cache sau non-cache, astfel încât clienții să nu primească date învechite sau incorecte ca răspuns la solicitările ulterioare. Memorarea corectă în cache ajută la eliminarea completă sau parțială a unor interacțiuni client-server, sporind și mai mult performanța și scalabilitatea sistemului.
4. Interfață uniformă
Cerințele fundamentale ale unei arhitecturi RESTful includ o interfață unificată și uniformă. Clientul trebuie să înțeleagă întotdeauna formatul și adresele pe care trebuie să le folosească atunci când trimite o solicitare, iar serverul, la rândul său, trebuie să înțeleagă și formatul pe care ar trebui să-l folosească atunci când răspunde la solicitările clientului. Această interacțiune consecventă client-server care descrie ce, unde, sub ce formă și cum se trimit date este o interfață unificată.
5. Straturi
Prin straturi, înțelegem structura ierarhică a rețelei. Uneori, un client poate comunica direct cu serverul, iar uneori comunică doar cu un nod intermediar. Utilizarea serverelor intermediare poate crește scalabilitatea datorită echilibrării încărcăturii și caching-ului distribuit. Să dăm un exemplu. Imaginați-vă o aplicație mobilă care este populară în întreaga lume. O parte integrantă a aplicației implică încărcarea imaginilor. Utilizatorii săi se numără în milioane, așa că un singur server nu poate face față unei sarcini atât de grele. Separarea sistemului în straturi va rezolva această problemă. Dacă clientul solicită o imagine de la un nod intermediar, atunci nodul intermediar solicită imaginea de la serverul care este cel mai puțin încărcat în acest moment și returnează imaginea clientului. Dacă memorarea în cache este aplicată corect la fiecare nivel al ierarhiei,
6. Cod la cerere (opțional)
Această constrângere implică faptul că clientul își poate extinde funcționalitatea prin descărcarea codului de pe server sub formă de applet-uri sau scripturi.
Avantajele unei arhitecturi RESTful
Aplicațiile care respectă toate constrângerile menționate mai sus au următoarele avantaje: fiabilitate (nu este nevoie să salvezi starea clientului, care s-ar putea pierde)
performanță (datorită utilizării unui cache)
scalabilitate
comunicare transparentă
interfețe simple
portabilitate
capacitatea de a face modificări cu ușurință
capacitatea de a evolua și de a se adapta la noile cerințe
Vom împărți prezentarea noastră de ansamblu asupra REST în trei părți:
GO TO FULL VERSION