Bazele REST API

Bazele REST API

De: Tree Web Solutions | Etichete: rest api, conceptul api, bazele rest api, protocol http, metode http, api

Introducere

Trăim într-o lume modernă și ultra-conectată, care partajează o cantitate imensă de date în fiecare secundă prin browsere, servere, software și aplicații. Pentru ca toate aceste sisteme să comunice între ele, avem un instrument care este jucătorul cheie pentru a integra toată această complexitate: API-urile.

În acest articol îmi împărtășesc cunoștințele, experiența și studiile despre această tehnologie, cu scopul de a oferi o înțelegere de bază a principalelor elemente fundamentale ale protocolului API, REST și HTTP.

1 Concept API

Mijloace API A plicarea P rogramming I nterface și, la fel ca orice altă interfață, permite interacțiuni. În cazul unui API, acesta permite interacțiuni între sisteme, urmând un set de standarde și protocoale pentru a partaja caracteristici, informații și date . Cu alte cuvinte, oferă dezvoltatorilor posibilitatea de a construi și proiecta produse și servicii care vor comunica cu alte produse și servicii.

Putem avea diferite stiluri arhitecturale de API - uri și, în prezent, cel principal , care este o parte cheie a lumii noastre de Internet se numește REST, un acronim pentru RE prezentaționale S lita T axele pe transfer.

2 Elemente fundamentale REST

REST este un stil de arhitectură pentru a dezvolta servicii web, care utilizează protocolul HTTP ca interfață de comunicație pentru a transfera date prin metode HTTP. Cu alte cuvinte, permite efectuarea manipulării datelor de bază în cadrul unei aplicații cu eficiență, cum ar fi crearea, recuperarea, actualizarea și ștergerea informațiilor.

REST s-a născut și a fost creat în 2000 de Roy Fielding în disertația sa de doctorat și, potrivit lui:

„Numele„ Transfer de stat reprezentativ ”este destinat să evoce o imagine a modului în care se comportă o aplicație Web bine concepută: o rețea de pagini web (o mașină de stare virtuală), în care utilizatorul progresează prin aplicație selectând linkuri (tranziții de stare ), rezultând ca pagina următoare (care reprezintă următoarea stare a aplicației) să fie transferată utilizatorului și redată pentru utilizarea acestora. ”

Deci, așa cum definește Roy Fielding, pentru a construi o aplicație web bine proiectată, putem folosi principiile REST care ne ajută să dezvoltăm servicii mai scalabile, mai fiabile și mai flexibile. Pentru a atinge acest obiectiv, arhitectura REST are șase constrângeri și un API care este condus de acesta poate fi numit RESTful .

2.1 Client-Server

Principiul principal al arhitecturii web Client-Server este Separarea preocupărilor, ceea ce înseamnă că Clientul care trimite cererea este complet independent de Serverul care returnează răspunsul .

2.2 Stateless

Toate informațiile (starea) necesare într-o cerere trebuie trimise de către Client. Prin urmare, Serverul nu trebuie să stocheze date în timpul unei comunicări Client-Server, ceea ce înseamnă că fiecare cerere este o solicitare independentă .

2.3 Cache

Cache-ul este o structură de stocare computațională axată pe păstrarea datelor stocate care sunt frecvent accesate, îmbunătățirea performanței și a eficienței rețelei. Prin urmare, prin cache, este posibil să se reducă sau chiar să se elimine necesitatea ca Clientul să trimită cereri către Server (care trebuie să informeze dacă cererea poate fi sau nu cache) .

2.4 Interface Uniform

Înseamnă modul în care clientul și serverul vor partaja informații prin definirea unei interfețe care trebuie urmată în fiecare solicitare. Cu alte cuvinte, este un contract între Client și Server care stabilește standardele pentru comunicarea acestora .

Aici avem patru constrângeri suplimentare care fac parte din Uniform Interface:

2.4.1 Identificarea resurselor

REST se bazează pe resurse, iar o resursă este o informație care poate fi denumită. Este utilizat într-o cerere pentru a identifica la ce dorește clientul să acceseze pe server .

De exemplu, pentru a prelua o listă products, resursa trebuie setată în adresa URL:http://api.example.com/products

2.4.2 Manipularea resurselor prin reprezentare

Clientul trebuie să fie sigur că cererea către serverul are suficiente informații pentru a manipula ( a crea, preluați, actualizați, ștergeți) resursa informat, care poate fi reprezentat de mai multe formate, cum ar fi JSON, XML, HTML , etc . Cu alte cuvinte, Clientul poate specifica reprezentarea dorită a unei resurse în fiecare cerere către un Server.

De exemplu: un client poate specifica într-o cerere de recuperare a unei resurse în format JSON.

2.4.3 Mesaje autodescriptive

Un mesaj autodescriptiv asigură o interfață uniformă în comunicare prin conținerea tuturor informațiilor de care un client sau un server are nevoie pentru a înțelege cererea și răspunsul doar prin verificarea semanticii mesajului.

2.4.4 HATEOAS (Hipertextul ca motor al stării aplicației)

HATEOAS înseamnă că un răspuns trimis de la server ar trebui să conțină informații despre ceea ce poate face Clientul în alte cereri. Cu alte cuvinte, Serverul indică ce acțiuni poate face Clientul în continuare. În standardele REST, serverele trebuie să trimită numai hipermedia (link-uri) către clienți.

2.5 Sistem stratificat

Sistemul stratificat se referă la faptul că pot exista mai multe componente și subsisteme între un client și un server. Cu alte cuvinte, clientul nu poate presupune că comunică direct către server și nu știe despre complexitatea procesării cererii și returnării răspunsului.

De exemplu: un client trimite o cerere către un server, dar mai întâi trece de un strat proxy pentru verificarea securității.

2.6 Cod la cerere

Code On Demand este singura constrângere opțională și înseamnă că un server poate trimite un cod executabil ca răspuns la client . Cu alte cuvinte, se întâmplă atunci când un browser, de exemplu, primește un răspuns de la server cu o etichetă HTML <script>, astfel încât, atunci când documentul HTML este încărcat, scriptul poate fi executat.

3 Solicitați Anatomie

Practic, o cerere de client are 4 elemente principale care compun toate informațiile necesare pentru a interacționa cu serverul .

3.1 URL

URL - ul înseamnă U niform R esource L ocator, care este adresa de a nu identifica doar o resursă, dar , de asemenea , pentru a specifica modul în care să - l acces. Într-un API, adresa URL poate fi denumită URL de bază, ceea ce înseamnă că aceasta este adresa de bază care va fi utilizată în fiecare cerere.

De exemplu: http://api.example.com

3.2 URI

URI -ul înseamnă U niform R esource I dentifier, care este utilizat în URL - ul pentru a specifica care resursa Clientul ar dori să acceseze într - o solicitare .

De exemplu: http://api.example.com/products

URL: http://api.example.com/
URI:/products

Prin urmare, fiecare adresă URL este un URI, dar nu toate URI-urile sunt adrese URL.

3.3 Parametri

Parametrii sunt informații care pot fi trimise într-o cerere de către Client pentru a influența răspunsul de către Server . REST are 4 tipuri de parametri, iar utilizarea sa va depinde de tipul de acțiune cerut de cerere.

3.4 Paramite corporale

Corpul, așa cum spune numele, este corpul cererii care conține toate datele de care serverul are nevoie pentru a procesa cu succes cererea. Prin urmare, este utilizat numai în cererile care trebuie să trimită informații, cum ar fi crearea sau actualizarea.

Exemplu de corp de solicitare în format JSON:

{
    “name”: “Laptop”,
    “price”: 1000
    “available”: true
}

3.5 Traseul Params

Parametrii rutei sunt parametri inserați în adresa URL cu informații pentru a identifica o anumită resursă pentru a întreprinde o acțiune, cum ar fi: preluați, editați, actualizați sau ștergeți.

De exemplu: http://api.example.com/products/1

În acest exemplu dat, ruta param cu valoarea 1 identifică resursa care va fi manipulată în cerere.

3.6 Interogare Params

Parametrii de interogare sunt, de asemenea, parametri introduși în adresa URL, dar cu diferența principală că cazurile de utilizare sunt legate de filtrarea și căutarea informațiilor despre o resursă, sau chiar paginarea și ordonarea rezultatelor .

De exemplu:

http://api.example.com/products?name=laptop&available=true

În acest exemplu dat, Clientul comunică serverului că cererea este de a prelua produse cu nume egal cu laptop, iar disponibil este egal cu adevărat.

3.7 Anteturi

Anteturile permit trimiterea de informații suplimentare într-o cerere , cum ar fi jetoane de autentificare și tipuri de conținut.

De exemplu:

Authorization: Bearer token
Accept: application/json

În acest exemplu dat, Clientul trimite date suplimentare, informând nu doar acreditările sale pentru a accesa o resursă, ci și formatul de răspuns dorit.

4 PROTOCOL HTTP

Bine, acum că avem o înțelegere de bază a fundamentelor REST și constrângerile Este, să vorbim despre standardul de comunicare ce guverneaza lumea la Internet prin definirea modelelor de interacțiune între clienți și servere : a protocolului HTTP ( H yperText T axele pe transfer P rotocol).

Protocolul HTTP determină nu doar metodele care sunt permise într-un API REST, ceea ce înseamnă tipurile de acțiuni pe care Clientul le poate solicita într-o cerere, ci și codurile de stare pe care Server le returnează ca răspuns pentru a avea un flux de comunicare bun .

4.1 Metode HTTP

Există 5 metode principale pe care un Client le poate folosi într-o cerere pentru a manipula o resursă API , care sunt legate de cele 5 tipuri de bază de manipulare a datelor dintr-o bază de date, cum ar fi: Creare, Preluare, Actualizare și Ștergere.

4.1.1 GET

Această metodă este utilizată pentru a extrage date de pe un server, indicând resursa în adresa URL. De exemplu, pentru a solicita o listă de produse ale unui API, Clientul poate trimite:

OBȚINE http://api.example.com/products

4.1.2 POST

Această metodă este utilizată pentru a crea o nouă resursă în server, indicând-o în adresa URL și trimitând datele resursei în corpul cererii.

De exemplu:

POST http://api.example.com/products

Solicitați corpul în format JSON:

{
    “name”: “Laptop II”,
    “price”: 1000
    “available”: true
}

În acest exemplu dat, un nou produs va fi creat în baza de date cu aceste informații furnizate.

4.1.3 PUT

Această metodă este utilizată pentru actualizarea datelor despre resurse în server prin identificarea lor în adresa URL și trimiterea informațiilor care vor fi actualizate în corpul cererii.

A PUNE http://api.example.com/products/1

Solicitați corpul în format JSON:

{
    “name”: “Laptop”,
    “price”: 5000,
    “available”: false
}

În acest exemplu dat, produsul cu ID-ul 1 va fi actualizat.

4.1.4 PATCH

Această metodă este, de asemenea, utilizată pentru a actualiza datele despre resurse în server, identificându-le în adresa URL, dar cu diferența principală de a actualiza doar o anumită informație .

PLASTURE http://api.example.com/products/1

Solicitați corpul în format JSON:

{
    “available”: true
}

În acest exemplu dat, doar availableproprietatea produsului cu ID-ul 1 va fi actualizată.

4.1.5 DELETE

Această metodă este utilizată pentru a șterge o resursă din server prin identificarea acesteia în adresa URL.

De exemplu:

ȘTERGE http://api.example.com/products/1

În acest exemplu dat, produsul cu ID 1 va fi șters.

4.2 Cod de stare HTTP

Codurile de stare HTTP sunt coduri returnate de server pentru a indica tipul de răspuns în cererea unui client , facilitând înțelegerea doar prin grupul și numărul său.

Cele mai frecvent utilizate grupuri și numere de cod de stare sunt:

4.2.1 Grupa 2

Grup de stare care indică o solicitare reușită .

4.2.2 Grupa 3

Grup de stare care indică răspunsurile de redirecționare , care sunt folosite pentru a informa Clientul că Serverul avea nevoie pentru a efectua o redirecționare către o nouă adresă URL.

4.2.3 Grupa 4

Grup de stare care indică o eroare în partea Client , ceea ce înseamnă că solicitarea a fost construită incorect.

4.2.4 Grupa 5

Grup de stare care indică o eroare în partea Server , ceea ce înseamnă că solicitarea a fost trimisă corect de către Client, dar a apărut o eroare la procesarea acesteia.

Concluzie

Sper că acest articol v-a ajutat să aveți o abordare teoretică de bază despre fundamentele REST, care este o cunoștință esențială pentru fiecare programator care dezvoltă servicii web.

Sursa: https://dev.to/cassiocappellari