ce este REST?

transfer de stare reprezentațională

REST, sau transfer de Stat reprezentațional, este un stil arhitectural pentru furnizarea de standarde între sistemele informatice de pe web, facilitând comunicarea între sisteme. Sistemele compatibile cu restul, adesea numite sisteme RESTful, se caracterizează prin modul în care acestea sunt apatride și separă preocupările Clientului și serverului. Vom analiza ce înseamnă acești Termeni și de ce sunt caracteristici benefice pentru serviciile de pe Web., în restul stilului arhitectural, implementarea clientului și implementarea serverului se poate face independent, fără ca fiecare să știe despre celălalt. Aceasta înseamnă că codul din partea clientului poate fi modificat în orice moment fără a afecta funcționarea serverului, iar codul din partea serverului poate fi modificat fără a afecta funcționarea clientului.atâta timp cât fiecare parte știe ce format de mesaje să trimită celeilalte, ele pot fi păstrate modulare și separate., Separând preocupările legate de interfața cu utilizatorul de preocupările legate de stocarea datelor, îmbunătățim flexibilitatea interfeței pe platforme și îmbunătățim scalabilitatea prin simplificarea componentelor serverului. În plus, separarea permite fiecărei componente capacitatea de a evolua independent.folosind o interfață REST, clienți diferiți ating aceleași obiective REST, efectuează aceleași acțiuni și primesc aceleași răspunsuri.,

apatridia

sistemele care urmează paradigma REST sunt apatride, ceea ce înseamnă că serverul nu trebuie să știe nimic despre starea în care se află clientul și invers. În acest fel, atât serverul, cât și Clientul pot înțelege orice mesaj primit, chiar fără a vedea mesajele anterioare. Această constrângere a apatridiei este aplicată prin utilizarea resurselor, mai degrabă decât prin comenzi. Resursele sunt substantivele Web – ele descriu orice obiect, document sau lucru pe care ar putea fi necesar să îl stocați sau să îl trimiteți altor servicii.,deoarece sistemele REST interacționează prin operații standard pe resurse, ele nu se bazează pe implementarea interfețelor.aceste constrângeri ajută aplicațiile RESTful să obțină fiabilitate, performanță rapidă și scalabilitate, ca componente care pot fi gestionate, actualizate și reutilizate fără a afecta sistemul în ansamblu, chiar și în timpul funcționării sistemului.acum, vom explora modul în care comunicarea dintre client și server se întâmplă de fapt atunci când implementăm o interfață RESTful.,

comunicare între Client și Server

în arhitectura REST, clienții trimit solicitări de preluare sau modificare a resurselor, iar serverele trimit răspunsuri la aceste solicitări. Să aruncăm o privire la modalitățile standard de a face cereri și de a trimite răspunsuri.

efectuarea cererilor

REST necesită ca un client să facă o solicitare către server pentru a prelua sau modifica datele de pe server.,șantajeze clienții să treacă de-a lungul informații despre cerere

HTTP Verbe

sunt 4 de bază HTTP verbe vom folosi în cererile de a interacționa cu resurse în RESTUL sistemului:

• GET — de a prelua o anumită resursă (de identitate) sau o colecție de resurse
• POST — creați o nouă resursă
• PUNE — update o anumită resursă (prin id)
• ștergere — pentru a ȘTERGE o anumită resursă cu id

puteți afla mai multe despre aceste verbe HTTP în următoarele Codecademy articolul:

• Ce este CRUD?,

anteturi și parametri de acceptare

în antetul cererii, clientul trimite tipul de conținut pe care îl poate primi de la server. Acesta se numește câmpul Accept și se asigură că serverul nu trimite date care nu pot fi înțelese sau prelucrate de client. Opțiunile pentru tipurile de conținut sunt tipuri MIME (sau extensii multifuncționale de e-Mail pe Internet, despre care puteți citi mai multe în documentele web MDN.,

Tipuri MIME, utilizate pentru a specifica tipurile de conținut în Accept domeniu, consta dintr-un type și un subtype. Ele sunt separate printr-o bară oblică (/).

de exemplu, un fișier text care conține HTML ar fi specificat cu tipul text/html. Dacă acest fișier text conținea CSS în schimb, acesta ar fi specificat ca text/css. Un fișier text generic ar fi notat ca text/plain. Această valoare implicită, text/plain, nu este totuși o captură., Dacă un client așteaptă text/cssși primește text/plain, nu va putea recunoaște conținutul.

Alte tipuri și frecvent utilizate subtipuri:

De exemplu, un client accesează o resursă cu id 23 într-un articles resurse pe un server s-ar putea trimite o cerere de genul asta:

Accept câmp de antet în acest caz se spune că clientul va accepta conținutul în text/html sau application/xhtml.,

căi

cererile trebuie să conțină o cale către o resursă pe care ar trebui să fie efectuată operația. În API-urile RESTful, căile ar trebui proiectate pentru a ajuta clientul să știe ce se întâmplă. în mod convențional, prima parte a căii ar trebui să fie forma plurală a resursei. Acest lucru păstrează căi imbricate simplu de citit și ușor de înțeles.

o cale ca fashionboutique.com/customers/223/orders/12 este clară în ceea ce indică, chiar dacă nu ați mai văzut această cale specifică înainte, deoarece este ierarhică și descriptivă., Putem vedea că suntem accesarea comenzii cu id 12 pentru client cu id

Căi trebuie să conțină informațiile necesare pentru a localiza o resursă cu gradul de specificitate necesare. Când vă referiți la o listă sau la o colecție de resurse, nu este întotdeauna necesar să adăugați un id. De exemplu, o cerere POST la fashionboutique.com/customers cale nu ar avea nevoie de o suplimentare de identificare, ca serverul va genera un id pentru noul obiect.,

dacă încercăm să accesăm o singură resursă, va trebui să adăugăm un id la cale.De exemplu:GET fashionboutique.com/customers/:id — extrage elementul din customers resursă cu id specificată.DELETE fashionboutique.com/customers/:id — șterge elementul din customers resursă cu id specificată.,

trimiterea răspunsurilor

tipuri de conținut

în cazurile în care serverul trimite o sarcină utilă de date către client, serverul trebuie să includă un content-type în antetul răspunsului. Acest câmp antet content-type avertizează clientul cu privire la tipul de date pe care le trimite în corpul de răspuns. Aceste tipuri de conținut sunt tipuri MIME, la fel cum sunt în câmpul accept din antetul cererii., content-type care serverul trimite înapoi în răspunsul ar trebui să fie una dintre opțiunile pe care clientul specificate în accept domeniul de solicitare.,

De exemplu, atunci când un client accesează o resursă cu id 23 într-un articles resurse cu asta Cerere:

serverul s-ar putea trimite înapoi conținutul cu antet de răspuns:

Acest lucru ar însemna că conținutul solicitat este în curs de a se întoarce în corp răspuns cu un content-type de text/html, ceea ce clientul a spus că ar fi capabil să accepte.,

coduri de răspuns

răspunsurile de la server conțin coduri de stare pentru a alerta clientul la informații despre succesul operațiunii. Ca un producător, nu trebuie să știe fiecare cod de stare (mulți dintre ei), dar ar trebui să știi cele mai comune și modul în care acestea sunt utilizate:

Pentru fiecare HTTP verb, nu sunt de așteptat coduri de stare un server ar trebui să se întoarcă la succes:

• IA — retur 200 (OK)
• POST — retur 201 (CREAT)
• PUNE — retur 200 (OK)
• ȘTERGE — retur 204 (FĂRĂ CONȚINUT)în Cazul în care operațiunea nu reușește, de a returna cele mai specifice cod de stare posibilă corespunzătoare problemă care a fost întâlnită., să presupunem că avem o aplicație care vă permite să vizualizați, să creați, să editați și să ștergeți clienții și comenzile pentru un mic magazin de îmbrăcăminte găzduit la fashionboutique.com. Am putea crea un API HTTP, care permite unui client pentru a efectua aceste funcții:

  Dacă ne-am dorit pentru a vizualiza toți clienții, cererea ar arata astfel:

  Un posibil răspuns antet ar arăta astfel:

  urmat de customers date solicitate în application/json format.,

  de a Crea un nou client prin postarea de date:

  apoi, serverul generează un id pentru acel obiect și se întoarce înapoi la client, cu o lovitură de cap, cum ar fi:

  Pentru a vizualiza un singur client prin specificarea acel client id:

  Un posibil răspuns antet ar arăta astfel:

  urmat de datele pentru customer resurse cu id 23 application/json format.,

  să Ne putem actualiza acel client de PUS ting noile date:

  Un posibil răspuns antet ar fi Status Code: 200 (OK), să notifice clientului, ca element cu id 123 a fost modificat.

  putem ȘTERGE, de asemenea, că clientul prin specificarea sale id:

  răspunsul ar fi un antet care conține Status Code: 204 (NO CONTENT), notificarea clientului că elementul cu id 123 a fost șters, și nimic la cadavru.,

  practicați cu odihnă

  să ne imaginăm că construim un site de colectare a fotografiilor. Vrem să facem un API pentru a urmări utilizatorii, locațiile și fotografiile acelor locuri. Acest site are un index.html și un style.css. Fiecare utilizator are un nume de utilizator și o parolă. Fiecare fotografie are un loc și un proprietar (adică utilizatorul care a făcut fotografia). Fiecare locație are un nume și o adresă stradală.,d=”229c60b6ce”>

  Request-POST /venuesResponse-201 (CREATED)Content-type: application/json

  Request-POST /venues/:id/photosResponse-201 (CREATED)Content-type: application/json

  PUT Requests

  Request-PUT /users/:idResponse-200 (OK)

  Request-PUT /venues/:idResponse-200 (OK)

  Request-PUT /venues/:id/photos/:idResponse-200 (OK)

  DELETE Requests

  Request-DELETE /venues/:idResponse-204 (NO CONTENT)

  Request-DELETE /venues/:id/photos/:idResponse-204 (NO CONTENT)