Transfer de stat reprezentativ

De la Wikipedia, enciclopedia liberă.
Salt la navigare Salt la căutare

Transferul de stare reprezentativă ( REST ) este un stil arhitectural ( arhitectură software ) pentru sisteme distribuite. Termenul transfer de stare reprezentativă și acronimul său, REST, a fost introdus în 2000 în teza de doctorat a lui Roy Fielding , [1] unul dintre principalii autori ai specificației Protocolului de transfer hipertext ( HTTP ) și au fost adoptate rapid de comunitatea internetului dezvoltatori.

Termenul REST reprezintă un sistem de transmitere a datelor prin HTTP fără straturi suplimentare, cum ar fi SOAP . Sistemele REST nu au conceptul de sesiune, adică sunt apatrizi , așa cum se discută mai jos.

Arhitectura REST se bazează pe HTTP. Operațiunea oferă o structură URL bine definită, care identifică în mod unic o resursă sau un set de resurse și utilizarea metodelor HTTP specifice pentru recuperarea informațiilor (GET), pentru modificare (POST, PUT, PATCH, DELETE) și în alte scopuri (OPȚIUNI etc. .). Acest aspect particular este detaliat în secțiunea „Relația dintre adresele URL și metodele HTTP”.

Principii

REST prezice că scalabilitatea și creșterea web au rezultat din câteva principii cheie de proiectare:

  • starea și funcționalitatea aplicației sunt împărțite în resurse web
  • fiecare resursă este unică și adresabilă utilizând sintaxa universală pentru utilizare în hyperlinkuri
  • toate resursele sunt partajate ca o interfață uniformă pentru transferul de stare între client și resurse, aceasta constând din:
    • un set constrâns de operațiuni bine definite
    • un set de conținut restricționat, acceptat opțional de cod la cerere
    • un protocol care este:

Fielding descrie efectul arhitecturii REST asupra scalabilității în acest mod:

( RO )

„Separarea preocupărilor client-server REST simplifică implementarea componentelor, reduce complexitatea semanticii conectorilor, îmbunătățește eficacitatea reglării performanței și mărește scalabilitatea componentelor pure ale serverului. Constrângerile de sistem stratificate permit intermediarilor - proxy-uri, gateway-uri și firewall - uri - să fie introduse în diferite puncte ale comunicației fără a schimba interfețele dintre componente, permițându-le astfel să asiste la traducerea comunicării sau să îmbunătățească performanța prin cache-ul partajat la scară largă. REST permite procesarea intermediară prin constrângerea mesajelor să fie autodescriptive: interacțiunea este apatridă între solicitări, metodele standard și tipurile de suporturi sunt utilizate pentru a indica semantica și a schimba informații, iar răspunsurile indică în mod explicit cache-ul. "

 ( IT )

„Separarea de interese REST client-server simplifică implementarea componentelor, reduce complexitatea semanticii conectorilor , îmbunătățește eficacitatea reglării performanței și mărește scalabilitatea componentelor pure ale serverului. Constrângerile de sistem stratificate permit intermediarilor - proxy - uri , gateway-uri și firewall - uri - să fie introduși în diferite puncte ale comunicației fără a schimba interfețele dintre componente, permițându-le să asiste la traducerea comunicării sau să îmbunătățească performanța prin cache partajat pe scară largă. REST permite procesarea intermediară prin constrângerea mesajelor să fie autodescriptivă: interacțiunea este apatridă între cereri, metodele de bază și tipurile de media sunt utilizate pentru a indica semantica și a schimba informații, iar răspunsurile indică în mod explicit capacitatea de a memora în cache. "

( Fielding , 2000 )

Constrângeri

Abordarea arhitecturală REST este definită de următoarele șase constrângeri aplicate unei arhitecturi, lăsând în același timp liberă implementarea componentelor individuale [2] .

Client - server . Un set uniform de interfețe separă clienții de servere . Această separare a rolurilor și sarcinilor înseamnă că, de exemplu, clientul nu trebuie să-și facă griji cu privire la salvarea informațiilor, care rămân în serverele individuale. În acest fel, portabilitatea codului client profită de acesta. Serverele nu trebuie să preia interfața grafică sau starea utilizatorului, astfel încât hardware - ul poate fi mai simplu și mai scalabil. Serverul și clientul pot fi înlocuite și dezvoltate independent, atâta timp cât interfața nu este modificată.

Apatrid . Comunicarea client-server este limitată, astfel încât niciun context client nu este stocat pe server între cereri. Fiecare cerere din partea diferiților clienți conține toate informațiile necesare pentru a solicita serviciul, iar starea sesiunii este conținută în client. Starea sesiunii poate fi transferată și către server printr-un alt serviciu de stocare persistent, cum ar fi o bază de date .

În cache . La fel ca în World Wide Web, clienții pot memora în cache răspunsurile. Acestea trebuie, în orice caz, definite implicit sau explicit ca cache sau nu, pentru a împiedica clienții să reutilizeze stări vechi și date incorecte. Gestionarea corectă a cache-ului poate reduce sau elimina parțial comunicațiile client-server, îmbunătățind scalabilitatea și performanța.

Sistem stratificat . Structura sistemului „stratificat” (literal din engleză) face posibilă, de exemplu, publicarea API-ului pe un server, stocarea datelor pe un al doilea server și gestionarea autentificării cererilor pe un al treilea server. Aceasta înseamnă că un client nu poate ști dacă este conectat direct la un server final sau la unul din lanț.

Cozi la cerere . (opțional) Serverele pot extinde sau personaliza temporar funcționalitatea clientului prin transferarea codului executabil. De exemplu , acest lucru poate include componente compilate , cum ar fi Java Applets sau limbaje de scripting , cum ar fi partea la nivel de client JavaScript . Conceptul de cod la cerere este singura constrângere opțională pentru definirea unei arhitecturi REST.

Interfață uniformă . O interfață de comunicație omogenă între client și server permite simplificarea și decuplarea arhitecturii, pentru a o putea modifica separat în blocuri.

Principiul fundamental al REST: resurse

Un concept important în REST este existența resurselor (surse de informații), care pot fi accesate printr-un identificator global (un URI ).

Pentru a utiliza resursele, componentele unei rețele (componente client și server) comunică printr-o interfață standard (cum ar fi HTTP) pentru a schimba reprezentări ale acestor resurse, care este documentul care transmite informațiile. De exemplu, o resursă de cerc ar putea accepta și returna o reprezentare care specifică un punct pentru centru și rază în format SVG , dar poate accepta și returna o reprezentare care specifică trei puncte distincte de-a lungul circumferinței în format CSV .

Orice număr de conectori ( client , server , cache , tunel etc.) pot media cererea, dar fiecare conector intervine fără a cunoaște „istoricul trecut” al celorlalte cereri; tocmai din acest motiv arhitectura REST este definită fără stare, spre deosebire de alte arhitecturi sau protocoale de stare . În consecință, o aplicație poate interacționa cu o resursă știind două lucruri: identificatorul resursei și acțiunea solicitată. Nu este necesar să știți dacă există proxy-uri , gateway-uri , firewall-uri , tuneluri sau alte mecanisme intermediare între acesta și server în care sunt prezente informațiile necesare.

Cu toate acestea, aplicația trebuie să cunoască formatul informațiilor returnate, adică reprezentarea acestora. De obicei, este un document HTML , XML sau JSON , dar poate fi și imagini sau alt conținut.

Relația dintre adresele URL și metodele HTTP

Următorul tabel arată modul în care metodele HTTP sunt de obicei utilizate într-un API RESTful:

Metode HTTP
Uniform Resource Locator (URL) OBȚINE A PUNE POST ȘTERGE
Colecție, cum ar fi http://api.example.com/resources/ Returnează o listă de resurse și, eventual, alte detalii despre articolele care aparțin colecției. Înlocuiește întreaga colecție cu o altă colecție. Creați un element nou în colecție. Codul de stare returnat de obicei este 201 (Creat). URI-ul noii resurse este atribuit automat și este de obicei returnat de această operațiune (locația antetului).[3] Ștergeți întreaga colecție.
Element, cum ar fi http://api.example.com/resources/item17 Preluează o reprezentare a articolului adresat în colecție (identificat de articolul 17), într-un format de date adecvat (tip media). Înlocuiește elementul adresat din colecție sau, dacă nu există, îl creează . Tratați articolul de colecție în conformitate cu propriile dvs. drepturi și creați un articol nou în interior.[3] În general nu se utilizează dacă se utilizează metoda PUT. Ștergeți elementul identificat din colecție.

Metoda GET este o metodă sigură, adică o metodă sigură sau nulă , ceea ce înseamnă că invocarea sa nu produce niciun efect secundar: recuperarea sau accesarea unei înregistrări nu o modifică.

Metodele PUT și DELETE sunt idempotente , ceea ce înseamnă că starea sistemului rămâne aceeași indiferent de numărul de repetări ale aceleiași cereri.

Spre deosebire de serviciile web bazate pe SOAP , nu există un standard oficial pentru API-urile web RESTful. [4] Acest lucru se datorează faptului că REST este un set de linii directoare pentru o arhitectură, în timp ce SOAP este un protocol.

REST nu este un standard în sine, dar implementările RESTful folosesc standarde, precum HTTP , URI , JSON și XML . [4]

Mulți dezvoltatori descriu, de asemenea, API-urile lor ca RESTful, chiar dacă aceste API-uri nu satisfac toate constrângerile arhitecturale descrise mai sus (în special interfața uniformă) [5] .

Notă

  1. ^ Capitolul 5 al tezei lui Fielding este intitulat Representational State Transfer (REST) .
  2. ^ (EN) Principii și constrângeri arhitecturale REST - Tutorial REST API pe restfulapi.net. Adus la 20 februarie 2020 .
  3. ^ a b Jeremy H, Exemplu API REST , There Is No Right Way , 16 mai 2012. Accesat la 31 iulie 2014 .
  4. ^ a b M Elkstein, Learn REST: A Tutorial , at rest.elkstein.org , blogger.com, februarie 2008. Accesat la 16 aprilie 2015 .
  5. ^ Andrea Chiarelli, Toată lumea vrea să se odihnească , pe html.it , 16 aprilie 2019. Adus pe 20 septembrie 2019 .

Bibliografie

Elemente conexe

linkuri externe

Controlul autorității LCCN (EN) sh2009000706 · GND (DE) 7592728-7
Adus de la „ https://it.wikipedia.org/w/index.php?title=Representational_State_Transfer&oldid=120058567 ”