REST este acronimul pentru transfer de Stat reprezentativ. Este stilul arhitectural pentru sistemele hipermedia distribuite și a fost prezentat pentru prima dată de Roy Fielding în 2000 în celebra sa disertație.

ca orice alt stil arhitectural, restul are, de asemenea, propriile 6 constrângeri de ghidare care trebuie satisfăcute dacă o interfață trebuie să fie menționată ca odihnitoare. Aceste principii sunt enumerate mai jos.,

Principii Directoare de RESTUL

1. Client–server – Prin separarea interfeței de utilizator se referă la preocupările de stocare a datelor, putem îmbunătăți portabilitatea interfață de utilizator pe mai multe platforme și de a îmbunătăți scalabilitatea prin simplificarea componente de server.
2. Stateless – fiecare cerere de la client la server trebuie să conțină toate informațiile necesare pentru a înțelege cererea și nu poate profita de niciun context stocat pe server. Prin urmare, starea sesiunii este păstrată în întregime pe client.,
3. constrângerile Cacheable – Cache necesită ca datele dintr-un răspuns la o cerere să fie etichetate implicit sau explicit ca fiind cacheable sau non-cacheable. Dacă un răspuns poate fi stocat în cache, atunci un cache client are dreptul de a reutiliza datele de răspuns pentru solicitări echivalente ulterioare.
4. interfață uniformă-prin aplicarea principiului generalității ingineriei software la interfața componentă, arhitectura generală a sistemului este simplificată și vizibilitatea interacțiunilor este îmbunătățită., Pentru a obține o interfață uniformă, sunt necesare mai multe constrângeri arhitecturale pentru a ghida comportamentul componentelor. Restul este definit de patru constrângeri de interfață: identificarea resurselor; manipularea resurselor prin reprezentări; mesaje auto-descriptive; și, hypermedia ca motor al stării aplicației.
5. sistem stratificat – stilul de sistem stratificat permite ca o arhitectură să fie compusă din straturi ierarhice prin constrângerea comportamentului componentelor, astfel încât fiecare componentă să nu poată „vedea” dincolo de stratul imediat cu care interacționează.,
6. cod la cerere – opțional) – REST permite extinderea funcționalității clientului prin descărcarea și executarea codului sub formă de applet-uri sau scripturi. Acest lucru simplifică clienții prin reducerea numărului de caracteristici necesare pentru a fi pre-implementate.

resursă

abstractizarea cheie a informațiilor în REST este o resursă. Orice informație care poate fi numită poate fi o resursă: un document sau o imagine, un serviciu temporal, o colecție de alte resurse, un obiect non-virtual (de exemplu, o persoană) și așa mai departe., REST utilizează un identificator de resurse pentru a identifica resursa particulară implicată într-o interacțiune între componente.

starea resursei la o anumită marcă de timp este cunoscută sub numele de reprezentare a resurselor. O reprezentare constă în date, metadate care descriu datele și link-uri hypermedia care pot ajuta clienții în trecerea la următoarea stare dorită.formatul de date al unei reprezentări este cunoscut sub numele de tip media. Tipul de suport identifică o specificație care definește modul în care trebuie procesată o reprezentare. Un API cu adevărat odihnitor arată ca hipertext., Fiecare unitate adresabilă de informații poartă o adresă, fie în mod explicit (de exemplu, link-ul și id atribute) sau implicit (de exemplu, derivate din definiția de tip media și structura de reprezentare).

Potrivit lui Roy Fielding:

Hypertext (sau hypermedia) înseamnă prezentarea simultană de informații și controlează astfel că informația devine accesibilitate prin care utilizatorul (sau automat) obține alegeri și selectează acțiuni. Amintiți-vă că hipertextul nu trebuie să fie HTML (sau XML sau JSON) pe un browser., Mașinile pot urma link-uri atunci când înțeleg formatul de date și tipurile de relații.

Mai mult, reprezentările resurselor trebuie să fie auto-descriptive: clientul nu trebuie să știe dacă o resursă este angajat sau dispozitiv. Ar trebui să acționeze pe baza tipului de media asociat resursei. Deci, în practică, veți ajunge să creați o mulțime de tipuri media personalizate-în mod normal, un tip media asociat cu o singură resursă.

fiecare tip de suport definește un model implicit de procesare., De exemplu, HTML definește un proces de randare pentru hipertext și comportamentul browserului în jurul fiecărui element. Nu are nicio legătură cu metodele de resurse GET/PUT/POST/ DELETE / … în afară de faptul că unele elemente de tip media vor defini un model de proces care merge ca „elementele de ancorare cu un atribut href creează un link hipertext care, atunci când este selectat, invocă o cerere de recuperare (GET) pe URI-ul corespunzător atributului href codificat CDATA.,”

metode de resurse

Un alt lucru important asociat cu REST este metodele de resurse care trebuie utilizate pentru a efectua tranziția dorită. Un număr mare de oameni se referă în mod greșit metodele de resurse la metodele HTTP GET/PUT/POST/DELETE.Roy Fielding nu a menționat niciodată nicio recomandare în jurul metodei care trebuie utilizată în ce condiție. Tot ce subliniază este că ar trebui să fie interfață uniformă. Dacă decideți că HTTP POST va fi folosit pentru actualizarea unei resurse – mai degrabă decât majoritatea oamenilor recomandă HTTP PUT – este în regulă și interfața aplicației va fi odihnitoare.,în mod ideal, tot ceea ce este necesar pentru a schimba starea resursei trebuie să facă parte din răspunsul API pentru acea resursă – inclusiv metodele și în ce stare vor părăsi reprezentarea.

un API REST ar trebui să fie introdus fără cunoștințe anterioare dincolo de URI-ul inițial (marcaj) și setul de tipuri media standardizate care sunt adecvate pentru publicul vizat (adică, așteptat să fie înțeles de orice client care ar putea utiliza API-ul)., Din acel moment, toate tranzițiile de stare ale aplicației trebuie să fie determinate de selectarea de către client a opțiunilor furnizate de server care sunt prezente în reprezentările primite sau implicate de manipularea de către utilizator a acestor reprezentări. Tranzițiile pot fi determinate (sau limitate de) cunoștințele clientului despre tipurile de media și mecanismele de comunicare a resurselor, ambele putând fi îmbunătățite din mers (de exemplu, code-on-demand).,

un Alt lucru care vă va ajuta în timp ce construirea Api Odihnitor este că de interogare bazate pe API rezultatele ar trebui să fie reprezentată de o listă de link-uri cu informații sumare, nu de tablouri originale reprezentări de resurse deoarece interogarea nu este un substitut pentru identificarea de resurse.

REST și HTTP nu sunt aceleași !!

o mulțime de oameni preferă să compare HTTP cu restul. Restul și HTTP nu sunt aceleași.

odihnă !,= HTTP

deși, deoarece REST intenționează, de asemenea, să facă web-ul (internetul) mai eficient și mai standard, el pledează pentru utilizarea mai strictă a principiilor REST. Și de aici oamenii încearcă să înceapă să compare REST cu web (HTTP). Roy fielding, în disertația sa, nu a menționat nicăieri nicio directivă de implementare – inclusiv orice preferință de protocol și HTTP. Până la timp, onorați cele 6 principii directoare ale odihnei, puteți apela interfața dvs. odihnitoare.,

În cele mai simple cuvinte, în restul stilului arhitectural, datele și funcționalitatea sunt considerate resurse și sunt accesate folosind URI-uri (Uniform Resource Identifiers). Resursele sunt acționate prin utilizarea unui set de operații simple, bine definite. Clienții și serverele fac schimb de reprezentări ale resurselor utilizând o interfață și un protocol standardizate-de obicei HTTP.resursele sunt decuplate de reprezentarea lor, astfel încât conținutul lor poate fi accesat într-o varietate de formate, cum ar fi HTML, XML, text simplu, PDF, JPEG, JSON și altele., Metadatele despre resursă sunt disponibile și utilizate, de exemplu, pentru a controla cache-ul, pentru a detecta erorile de transmisie, pentru a negocia formatul de reprezentare adecvat și pentru a efectua autentificarea sau controlul accesului. Și cel mai important, fiecare interacțiune cu o resursă este apatridă.toate aceste principii ajută aplicațiile RESTful să fie simple, ușoare și rapide.