REST reprezintă transferul de Stat reprezentativ, un termen inventat de Roy Fielding în 2000. Este un stil de arhitectură pentru proiectarea aplicațiilor cuplate slab prin HTTP, care este adesea folosit în dezvoltarea serviciilor web. REST nu pune în aplicare nici o regulă cu privire la modul în care ar trebui să fie puse în aplicare la nivel inferior, a pus doar linii directoare de proiectare la nivel înalt și vă lasă să se gândească la propria implementare.
în ultimul meu loc de muncă, am proiectat API-uri odihnitoare pentru o companie majoră de telecomunicații timp de doi ani buni. În această postare, îmi voi împărtăși gândurile în afară de practicile standard de proiectare. Este posibil să nu fiți de acord cu mine cu privire la câteva puncte și este perfect OK. Voi fi fericit să discut orice de la tine cu o minte deschisă.
să începem cu lucruri specifice de design standard pentru a clarifica ce vrea Roy Fielding să construim. Apoi vom discuta despre gândurile mele, care vor fi mai mult spre puncte mai fine în timp ce vă proiectați API-urile odihnitoare.
constrângeri arhitecturale
REST definește 6 constrângeri arhitecturale care fac orice serviciu web – un adevărat API RESTful.
- interfață uniformă
- Client-server
- apatrid
- Cacheable
- sistem stratificat
- cod la cerere (opțional)
interfață uniformă
deoarece se aplică numele constrângerii, trebuie să decideți interfața API pentru resursele din interiorul sistemului care sunt expuse consumatorilor API și urmați religios. O resursă din sistem ar trebui să aibă un singur URI logic și care ar trebui să ofere o modalitate de a prelua date conexe sau suplimentare. Este întotdeauna mai bine să sinonimizați o resursă cu o pagină web.
orice resursă unică nu ar trebui să fie prea mare și să conțină fiecare și totul în reprezentarea sa. Ori de câte ori este relevant, o resursă ar trebui să conțină linkuri (HATEOAS) care indică URI-uri relative pentru a prelua informații conexe.
de asemenea, reprezentările resurselor din sistem ar trebui să urmeze instrucțiuni specifice, cum ar fi convențiile de denumire, formatele de legătură sau formatul de date (XML sau/și JSON).
toate resursele ar trebui să fie accesibile printr-o abordare comună, cum ar fi HTTP GET și modificate în mod similar folosind o abordare consecventă.
Client–server
această constrângere înseamnă în esență că aplicația client și aplicația server trebuie să poată evolua separat fără nicio dependență una de cealaltă. Un client ar trebui să știe doar URI-uri de resurse și asta este tot. Astăzi, aceasta este o practică standard în dezvoltarea web, deci nu este nevoie de nimic fantezist din partea ta. Păstrați-l simplu.
apatrid
Roy Fielding s-a inspirat din HTTP, așa că se reflectă în această constrângere. Faceți toate interacțiunile client-server apatride. Serverul nu va stoca nimic despre cea mai recentă solicitare HTTP făcută de client. Va trata fiecare cerere ca fiind nouă. Fără sesiune, fără istorie.
dacă aplicația client trebuie să fie o aplicație stateful pentru utilizatorul final, în cazul în care utilizatorul se conectează o dată și de a face alte operațiuni autorizate după aceea, atunci fiecare cerere de la client ar trebui să conțină toate informațiile necesare pentru a servi cererea-inclusiv autentificare și autorizare detalii.
Cacheable
în lumea de astăzi, cache de date și răspunsuri este de cea mai mare importanță ori de câte ori acestea sunt aplicabile/posibil. Pagina web pe care o citiți aici este, de asemenea, o versiune cache a paginii HTML. Caching aduce îmbunătățirea performanței pentru client-side și mai bine domeniul de aplicare pentru scalabilitate pentru un server, deoarece sarcina a redus.
în REST, cache-ul se aplică resurselor atunci când este cazul, iar apoi aceste resurse trebuie să se declare cache. Cache-ul poate fi implementat pe server sau pe partea clientului.
sistem stratificat
REST vă permite să utilizați o arhitectură de sistem stratificată în care implementați API-urile pe serverul a și să stocați date pe serverul B și să autentificați cererile în serverul C, de exemplu. Un client nu poate spune în mod obișnuit dacă este conectat direct la serverul final sau la un intermediar pe parcurs.
cod la cerere (opțional)
Ei bine, această constrângere este opțională. De cele mai multe ori, veți trimite reprezentările statice ale resurselor sub formă de XML sau JSON. Dar atunci când aveți nevoie, sunteți liber să return executable code pentru a sprijini o parte a cererii dumneavoastră, de exemplu, clienții pot apela API-ul pentru a obține un cod de redare widget UI. Este permis.
observați că toate constrângerile de mai sus sunt cel mai strâns legate de WWW (web). Folosind API-uri RESTful, puteți face același lucru cu serviciile dvs. web ceea ce faceți cu paginile web.