Prezentare generală a REST. Partea 2: Comunicarea dintre un client și un server

Prezentare generală a REST. Partea 1: Ce este REST? În această parte, ne vom aprofunda în modul în care are loc comunicarea între un client și un server. Pe parcurs, vom descoperi noi termeni și îi vom explica. Pentru a ne asigura că totul este clar, vom analiza comunicarea client-server folosind o aplicație RESTful ca exemplu. Să presupunem că dezvoltăm o aplicație web care stochează informații despre clienți și comenzile acestora. Cu alte cuvinte, sistemul nostru este capabil să efectueze operațiuni asupra anumitor entități: să le creeze, să le editeze și să le ștergă și să afișeze informații despre ele. Aceste entități vor fi:

• clienti (clienti)
• comenzi (comenzi clienți)
• articole (produse)

Într-o arhitectură RESTful, clienții trimit cereri către un server pentru a prelua sau modifica date, iar apoi serverele trimit clienților răspunsuri la cererile lor.

Cereri

Solicitările clienților sunt aproape întotdeauna făcute folosind protocolul HTTP. În general, solicitările HTTP constau din mai multe componente:

• Metoda HTTP
• antet
• URI
• organismul de cerere

Mai jos vom lua în considerare fiecare componentă mai detaliat.

URI-uri și resurse

Datele pe care clienții le primesc sau le modifică prin solicitări se numesc resurse. Comunicarea client-server se referă la manipularea resurselor. În REST, resursele sunt orice căruia îi poți da un nume. Într-un fel, ele sunt ca clasele în Java. În Java, putem crea o clasă pentru orice. Deci, în REST, o resursă poate fi orice: un utilizator, un document, un raport, o comandă. Poate fi fie o abstractizare a unei entități, fie ceva specific, de exemplu, o imagine, un videoclip, o animație sau un fișier PDF. În exemplul nostru, avem 3 resurse:

• clienti (clienti)
• comenzi (comenzi clienți)
• articole (produse)

Clienții trimit cereri către locații de resurse cunoscute sub numele de puncte finale. Mai simplu, un punct final este ca o adresă în rețea. Scufundându-ne mai adânc, putem spune că un punct final este un URI, adică o secvență de caractere care identifică o resursă abstractă sau fizică. Identificator uniform de resurse (URI) Uneori, un punct final, sau URI, este numit cale, adică calea către o resursă. În scopul acestui articol, vom folosi termenul URI. Fiecare resursă specifică trebuie să aibă un URI unic. Dezvoltatorul serverului este responsabil să se asigure că fiecare resursă are întotdeauna propriul URI. În exemplul nostru, noi suntem dezvoltatorii, așa că o vom face așa cum știm. Așa cum este adesea obișnuit să atribuiți identificatori numerici ca chei primare într-o bază de date relațională, fiecare resursă are și propriul său ID în REST. ID-ul resursei din REST se potrivește adesea cu ID-ul înregistrării din baza de date care stochează informații despre resursă. URI-urile REST încep de obicei cu forma de plural a unui substantiv care descrie o resursă. De exemplu, "

• /clienți — URI al tuturor clienților disponibili
• /customers/23 — URI al unui anumit client, adică clientul cu ID=23
• /customers/4 — URI al unui anumit client, adică clientul cu ID=4.

Dar asta nu este tot. Putem extinde URI-ul adăugând comenzi:

• /customers/4/orders — URI al tuturor comenzilor efectuate de clientul nr. 4
• /clienti/1/comenzi/12 — URI al comenzii nr.12 realizat de clientul nr.1.

Dacă continuăm expansiunea adăugând mai multe produse, obținem:

• /clienți/1/comenzi/12/items — URI al listei tuturor produselor din comanda nr. 12 realizată de clientul nr. 1.

Pe măsură ce adăugăm niveluri de imbricare, lucrul important este să facem URI-urile intuitive.

Metoda HTTP

Metoda HTTP este o secvență de orice caractere (cu excepția caracterelor de control și a delimitatorilor), care indică operația principală care se efectuează pe resursă. Există mai multe metode HTTP comune. Vom enumera cele care sunt utilizate cel mai des în serviciile RESTful:

• GET — Obțineți informații despre o anumită resursă (prin ID-ul acesteia) sau despre o colecție de resurse
• POST — Creați o resursă nouă
• PUT — Schimbați o resursă (prin ID-ul acesteia)
• DELETE — Ștergeți o resursă (prin ID-ul acesteia)

Anteturi

Solicitările, precum și răspunsurile, conțin anteturi HTTP. Ele transmit informații suplimentare despre cerere (sau răspuns). Anteturile sunt perechi cheie-valoare. Puteți vizualiza lista cu cele mai comune anteturi pe Wikipedia . În ceea ce privește REST, clienții trimit adesea un antet „Accept” în cereri către server. Acest antet este necesar pentru a spune serverului ce format în care clientul se așteaptă să primească un răspuns. Diverse formate sunt date într-o listă de tipuri MIME. MIME (Multipurpose Internet Mail Extensions) este o specificație pentru codificarea informațiilor și formatarea mesajelor astfel încât acestea să poată fi trimise prin Internet. Fiecare tip MIME este format din două părți separate printr-o bară oblică - un tip și un subtip. Exemple de tipuri MIME pentru diferite tipuri de fișiere:

• text — text/plain, text/css, text/html
• imagine — imagine/png, imagine/jpeg, imagine/gif
• audio — audio/wav, audio/mpeg
• video — video/mp4, video/ogg
• aplicație — application/json, application/pdf, application/xml, application/octet-stream

De exemplu, o solicitare poate avea un antet ca acesta:

Accept:application/json

Acest antet îi spune serverului că clientul se așteaptă să primească un răspuns în format JSON.

Corpul cererii

Acesta este mesajul trimis de client către server. Dacă cererea are un corp sau nu, depinde de tipul solicitării HTTP. De exemplu, cererile GET și DELETE, în general, nu conțin niciun corp de cerere. Dar cererile PUT și POST pot - depinde doar de scopul solicitării. La urma urmei, pentru a primi și/sau șterge date folosind un ID (care este transmis în URL), nu trebuie să trimiteți date suplimentare către server. Dar pentru a crea o resursă nouă (printr-o solicitare POST), trebuie să trimiteți resursa. Același lucru este valabil și pentru modificarea unei resurse existente. În REST, corpul solicitării este cel mai adesea trimis în format XML sau JSON. Formatul JSON este cel mai comun. Să presupunem că vrem să trimitem o cerere către server pentru a crea o nouă resursă. Daca nu ai uitat, am luat în considerare exemplul unei aplicații care gestionează comenzile clienților. Să presupunem că vrem să ne creăm un client nou. În cazul nostru, stocăm următoarele informații despre client: Nume, e-mail, număr de telefon. Apoi, corpul cererii ar putea fi următorul JSON:

{
  "name" : "Amigo",
  "email" : "amigo@jr.com",
  "phone" : "+1 (222) 333-4444"
}

Adunarea cererilor împreună

Deci, am examinat ce ar putea fi într-o solicitare a clientului. Vom oferi acum câteva exemple de solicitări împreună cu descrieri

Răspunsuri

Să spunem câteva cuvinte despre răspunsurile serverului. Un răspuns constă de obicei din următoarele părți:

• cod de răspuns
• antete
• organism de răspuns

În general, anteturile de răspuns nu diferă mult de anteturile cererii. În plus, unele anteturi sunt folosite atât în ​​răspunsuri, cât și în solicitări. Cred că totul este clar și în ceea ce privește organul de solicitare. Organismul returnează adesea informațiile solicitate de client. Informațiile returnate ca răspuns la solicitările GET pot fi, de asemenea, în format JSON. Dar ultima parte este puțin mai interesantă.

coduri de răspuns HTTP

Să luăm în considerare codurile de răspuns HTTP mai detaliat. Un cod de stare HTTP face parte din prima linie a unui răspuns de server la solicitările făcute prin protocolul HTTP. Este un număr întreg format din trei cifre zecimale. Prima cifră indică clasa codului de stare a răspunsului. Codul de răspuns este de obicei urmat de o frază explicativă în limba engleză, separată de un spațiu. Această frază este un motiv care poate fi citit de om pentru răspuns. Exemple:

• 201 Creat
• 401 Neautorizat
• 507 Depozitare insuficientă

Codul de răspuns îi spune clientului rezultatul solicitării și îi permite să determine ce acțiuni să întreprindă în continuare. Codurile de răspuns sunt împărțite în mai multe clase sau grupuri:

• 1XX — Informațional
• 2XX — Aceste coduri indică faptul că cererea clientului a fost primită și procesată cu succes
• 3XX — Aceste coduri informează clientul că trebuie făcută o cerere suplimentară, de obicei către un alt URI, pentru a finaliza cu succes operația
• 4XX — Eroare client. Astfel de coduri pot rezulta dintr-o cerere compusă incorect. Un alt exemplu este binecunoscutul cod „404 Not Found”, care poate apărea atunci când un client solicită o resursă inexistentă
• 5XX — Eroare de server. Aceste coduri sunt returnate clientului dacă serverul este responsabil pentru eșecul operațiunii

Prezentare generală a REST. Partea 3: Construirea unui serviciu RESTful pe Spring Boot