ODIHNĂ

Versiunea actuală a paginii nu a fost încă examinată de colaboratori experimentați și poate diferi semnificativ de versiunea revizuită pe 4 mai 2022; verificările necesită 5 modificări .

REST (din limba engleză . Representational  State Transfer - „ transferul  unui stat reprezentativ” sau „transmiterea unui” „stat” auto-descriere) este un stil arhitectural de interacțiune între componentele unei aplicații distribuite într- o rețea . Cu alte cuvinte, REST este un set de reguli pentru modul în care un programator organizează codarea unei aplicații server, astfel încât toate sistemele să poată schimba cu ușurință date și aplicația să poată fi scalată. [1] REST este un set consistent de constrângeri de luat în considerare atunci când proiectați un sistem hipermedia distribuit . În anumite cazuri ( magazine online , motoare de căutare , alte sisteme bazate pe date) acest lucru duce la o performanță mai bună și o arhitectură simplificată. Într-un sens larg[ clarifica ] Componentele din REST interacționează la fel ca clienții și serverele interacționează pe World Wide Web . REST este o alternativă la RPC [2] .

Pe Internet , un apel de procedură la distanță poate fi o cerere HTTP normală (de obicei GET sau POST ; o astfel de solicitare se numește „cerere REST” ), iar datele necesare sunt transmise ca parametri de cerere [3] [4] .

Pentru serviciile web construite având în vedere REST (adică fără încălcarea restricțiilor impuse de acesta), este folosit termenul „ RESTful ”.

Spre deosebire de serviciile web (servicii web) bazate pe SOAP , nu există un standard „oficial” pentru API-ul web RESTful. Ideea este că REST este un stil arhitectural , în timp ce SOAP este un protocol. Deși REST nu este un standard în sine, majoritatea implementărilor RESTful folosesc standarde precum HTTP , URL , JSON și, mai puțin frecvent, XML .

Istoria termenului

Deși acest concept se află chiar la temelia World Wide Web , termenul „REST” a fost introdus de Roy Fielding , unul dintre creatorii protocolului „ HTTP ”, abia în 2000 [4] . În disertația sa „Architectural Styles and the Design of Network-based Software Architectures” [5] de la Universitatea din California, Irvine [3] , el a oferit un cadru teoretic pentru modul în care clienții și serverele interacționează în World web , abstragându-l și numindu-l „transfer de stat reprezentativ” (“Transfer de stat reprezentativ” ) . Fielding a descris conceptul de construire a unei aplicații distribuite, în care fiecare cerere (cerere REST) ​​de la client către server conține informații cuprinzătoare despre răspunsul dorit al serverului (starea reprezentantului dorit), iar serverul nu este obligat să salveze informații despre stare. a clientului („sesiunea client”).

Stilul „REST” a evoluat în paralel cu „ HTTP 1.1 ” dezvoltat în 1996-1999, bazându-se pe designul existent „ HTTP 1.0” dezvoltat în 1996 [6] .

Proprietăți ale arhitecturii REST

Proprietăți arhitecturale care depind de restricțiile impuse sistemelor REST:

Roy Fielding, unul dintre principalii autori ai specificației protocolului HTTP, descrie impactul arhitecturii REST asupra scalabilității după cum urmează:

Cerințele arhitecturii REST

Există șase constrângeri obligatorii pentru construirea de aplicații REST distribuite conform Fielding [3] [7] .

Aceste restricții sunt obligatorii pentru sistemele REST [8] [9] . Restricțiile impuse determină modul în care serverul funcționează în ceea ce privește modul în care poate procesa și răspunde solicitărilor clienților. Funcționând în cadrul acestor constrângeri, sistemul dobândește proprietăți dezirabile, cum ar fi performanța, scalabilitatea, simplitatea, adaptabilitatea, portabilitatea, trasabilitatea și fiabilitatea.

Dacă aplicația de serviciu încalcă oricare dintre aceste condiții restrictive, sistemul nu poate fi considerat un sistem REST [3] .

Condițiile-restricțiile obligatorii sunt:

1. Model client-server

Prima limitare care se aplică modelului hibrid este aducerea arhitecturii la modelul client-server. Delimitarea nevoilor este principiul care stă la baza acestei restricții impuse. Separarea nevoilor interfeței client de nevoile serverului care stochează datele crește portabilitatea codului interfeței client către alte platforme, în timp ce simplificarea back-end-ului îmbunătățește scalabilitatea. Poate cel mai mare impact asupra World Wide Web este demarcarea în sine, care permite părților separate să se dezvolte independent una de cealaltă, susținând nevoile de dezvoltare ale Internetului de la diverse organizații. [3]

2. Lipsa statului

Protocolul de interacțiune dintre client și server necesită următoarea condiție: în perioada dintre solicitările clientului, pe server nu sunt stocate informații despre starea clientului ( protocol fără stat sau „protocol fără stat”). Toate cererile de la client trebuie să fie elaborate în așa fel încât serverul să primească toate informațiile necesare pentru a finaliza cererea. Starea sesiunii este salvată pe partea clientului [3] . Informațiile despre starea sesiunii pot fi transmise de către server unui alt serviciu (de exemplu, unui serviciu de bază de date) pentru a menține o stare stabilă, de exemplu, pentru perioada de stabilire a unei autentificări. Clientul inițiază trimiterea cererilor atunci când este gata (necesar) să treacă într-o stare nouă.

Î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ă.

3. Memorarea în cache

Ca și în cazul World Wide Web , clienții, precum și gazdele intermediare, pot stoca în cache răspunsurile serverului. Răspunsurile serverului, la rândul lor, trebuie să fie marcate în mod explicit sau implicit ca cacheable sau non-cache pentru a preveni clienții să primească date învechite sau incorecte ca răspuns la solicitările ulterioare. Utilizarea corectă a memoriei cache poate elimina parțial sau complet unele interacțiuni client-server, crescând și mai mult performanța și scalabilitatea sistemului.

4. Uniformitatea interfeței

A avea o interfață unificată este o cerință fundamentală de proiectare pentru serviciile REST [3] . Interfețele unificate permit fiecărui serviciu să evolueze independent.

Interfețele unificate sunt supuse următoarelor patru constrângeri [10] [11] :

Identificarea
resurselor Toate resursele sunt identificate în cereri, de exemplu folosind URI -uri în sistemele de Internet. Resursele sunt separate conceptual 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 pe partea serverului.

Manipularea resurselor printr-o reprezentare
Dacă un client stochează o reprezentare a unei resurse, inclusiv metadate, are suficiente informații pentru a modifica sau șterge resursa.

Mesaje „autodescriere”
Fiecare mesaj conține suficiente informații pentru a înțelege cum să-l proceseze. De exemplu, handlerul de mesaje (parser) necesar pentru extragerea datelor poate fi specificat în lista de tipuri MIME [3] .

Hypermedia ca mijloc de schimbare a stării aplicației ( HATEOAS )
Clienții schimbă starea sistemului numai prin acțiuni care sunt definite dinamic în hypermedia pe server (de exemplu, hyperlinkuri în hypertext ). Excluzând punctele simple de intrare în aplicație, un client nu poate presupune că o operațiune este disponibilă pe o resursă decât dacă a fost informat despre aceasta în solicitările anterioare către server. Nu există un format universal pentru furnizarea de legături între resurse, Web Linking ( RFC 5988 -> RFC 8288 ) și JSON Hypermedia API Language Arhivat 27 iunie 2014 la Wayback Machine sunt două formate populare pentru furnizarea de legături în serviciile REST HYPERMEDIA.

5. Straturi

Clientul nu este de obicei capabil să determine cu exactitate dacă comunică direct cu serverul sau cu un nod intermediar, din cauza structurii ierarhice a rețelelor (implicând că o astfel de structură formează straturi ). Utilizarea serverelor intermediare poate crește scalabilitatea prin echilibrarea încărcăturii și stocarea în cache distribuită . Nodurile intermediare pot face, de asemenea, obiectul unei politici de securitate pentru a asigura confidențialitatea informațiilor [12] .

6. Cod la cerere (limitare opțională)

REST poate permite extinderea funcționalității clientului prin descărcarea codului de pe server sub formă de applet -uri sau scripturi . Fielding susține că constrângerea suplimentară permite proiectarea unei arhitecturi care să susțină funcționalitatea dorită în cazul general, dar poate cu excepții în unele contexte.

Beneficii

Roy Fielding a subliniat că aplicațiile care nu îndeplinesc condițiile de mai sus nu pot fi numite aplicații REST. Dacă sunt îndeplinite toate condițiile, atunci, în opinia sa, cererea va primi următoarele avantaje [3] [7] :

Note

  1. ↑ Ce este REST API  (rusă)  ? . Preluat la 11 august 2021. Arhivat din original la 11 august 2021.
  2. ↑ Mashnin Timur Sergheevici. Tehnologia serviciilor web platformei Java. - BHV-Petersburg, 2012. - S. 115. - 560 p. — ISBN 978-5-9775-0778-3 .
  3. ↑ 1 2 3 4 5 6 7 8 9 10 Capitolul 5 al disertației lui Roy Fielding „Representational State Transfer (REST)” Arhivat 13 mai 2021 la Wayback Machine
  4. ↑ 1 2 Fielding discutând definiția termenului REST . tech.groups.yahoo.com. Consultat la 28 noiembrie 2013. Arhivat din original la 22 octombrie 2010.
  5. ↑ Teza Fielding: CAPITOLUL 5: Transferul de stat reprezentativ (REST) ​​. www.ics.uci.edu. Preluat la 1 decembrie 2015. Arhivat din original la 13 mai 2021.
  6. ↑ rest-discuss : Mesaj: Re: [rest-discuss RFC for REST?] (11 noiembrie 2009). Preluat la 1 decembrie 2015. Arhivat din original la 11 noiembrie 2009.
  7. ↑ 1 2 Thomas Erl, Benjamin Carlyle, Cesare Pautasso, Raj Balasubramanian. 5.1 // SOA cu REST. - Prentice Hall, 2013. - ISBN 978-0-13-701251-0 .
  8. ↑ Thomas Erl, Benjamin Carlyle, Cesare Pautasso, Raj Balasubramanian. 5.1 // SOA cu REST  (neopr.) / Thomas Erl. - Prentice Hall , 2013. - ISBN 978-0-13-701251-0 .
  9. ↑ Richardson, Leonard & Ruby, Sam (2007), RESTful Web service , O'Reilly Media, ISBN 978-0-596-52926-0 , < https://books.google.com/books?id=XUaErakHsoAC > . Preluat la 18 ianuarie 2011. Arhivat la 19 februarie 2012 la Wayback Machine 
  10. ↑ Wilde, Pautasso, 2011 , REST Definition.
  11. ↑ N. L. Podkolodny, A. V. Semenychev, D. A. Rasskazov, V. G. Borovsky, E. A. Ananko, E. V. Ignatieva, N. N. Podkolodnaya, O. A. Podkolodnaya, N A. Kolchanov Sistem distribuit de rețele web RESTful și analiză a rețelelor de gene. Vavilov Journal of Genetics and Breeding, vol. 16, N 4/1, 2012
  12. ↑ Hartley Brody. Cum HTTPS protejează conexiunile: Ce ar trebui să  știe fiecare dezvoltator web . Arhivat din original pe 24 decembrie 2015.

Literatură

Link -uri

  Accesați articolul Wikidata  În cataloagele bibliografice