Veți întâlni adesea REST și gRPC atunci când aveți de-a face cu API-uri. Chiar dacă Rest a dominat acest domeniu de mulți ani, gRPC se dovedește a fi un concurent demn.
Rest și gPRC sunt două moduri diferite prin care puteți proiecta un API. API-urile acționează ca o punte de comunicare între servicii care pot reprezenta sisteme complexe care rezidă în computere diferite sau scrise în limbi diferite.
Acest articol va prezenta atât Restul, cât și gRPC, vă va împărtăși asemănările, diferențele și unde să le folosiți pe fiecare.
Cuprins
Ce este Odihna?
Odihnă (Representational State Transfer) este o abordare software arhitecturală care dictează reguli cu privire la modul în care componentele software fac schimb de date. Restul se bazează pe protocolul de comunicare standard al web, HTTP.
Toate API-urile bazate pe stilul arhitectural REST sunt numite API-uri RESTful. Pe de altă parte, serviciile web care urmează designul arhitectural REST sunt cunoscute ca servicii web RESTful.
Stilul arhitectural REST este ghidat de aceste principii;
- Interfață uniformă: serverul ar trebui să transfere date într-un format standard. Cu toate acestea, datele transportate pot fi într-un format diferit de reprezentarea internă a resursei aplicației server.
- Apatridia: serverul ar trebui să completeze fiecare cerere client în mod independent, indiferent de solicitările anterioare. Solicitările clienților pentru resurse pot fi în orice ordine și fiecare solicitare este izolată de restul.
- Sistem stratificat: Prezintă un strat de intermediari autorizați între server și client. Clientul se poate conecta cu acești intermediari autorizați și totuși primește răspunsuri de la server.
- Cacheabilitate: Unele răspunsuri sunt stocate pe un intermediar sau pe client pentru a îmbunătăți timpul de răspuns.
- Cod la cerere: Serverele personalizează sau extind temporar funcționalitatea clientului prin transferul codului de programare software către client.
Beneficiile REST
- Scalabil: API-urile REST sunt cunoscute pentru scalabilitatea lor, deoarece optimizează interacțiunile client-server. Memorarea în cache și apatridia sunt caracteristicile majore care reduc încărcarea serverului.
- Flexibil: API-urile RESTful oferă separare totală client-server. Astfel de servicii vor decupla și simplifica diverse componente ale serverului, care pot evolua independent.
- Independență: puteți scrie aplicații server și client în diferite limbaje de programare fără a afecta designul API.
Cazuri de utilizare a Rest
- API-uri web
- Servicii web
- Arhitectura microserviciilor
Ce este gRPC?
gRPC este un cadru Remote Procedure Call (RPC) care poate rula în orice mediu. Acest cadru open-source este conceput ca un protocol de înaltă performanță care poate conecta eficient serviciile în și în centrele de date.
O aplicație client poate apela o metodă pe o aplicație server pe o altă mașină ca și cum ar fi un obiect local. Cu gRPC, definiți un serviciu și specificați metodele pe care le puteți apela de la distanță cu parametrii și tipurile de returnare ale acestora.
gRPC are suport pentru verificarea stării de sănătate, autentificare, echilibrare a încărcăturii și urmărire. Acest cadru folosește HTTP 2 și Protocol Buffer-uri pentru transmiterea datelor. Când se fac schimb de date, este apelată o procedură în loc de adresa URL a resursei
Beneficiile gRPC
- Scalabil: gRPC vă permite să instalați medii de rulare cu o singură comandă și să începeți să scalați milioane de RPC-uri/secundă.
- Definiție simplă a serviciului: utilizați Protocol Buffers pentru a vă defini serviciile și a le pune în funcțiune.
- Multiplatformă: acest cadru generează stub-uri idiomatice pentru client și server pentru diferite platforme și limbi.
- Streaming bidirecțional și autentificare integrată.
Cazuri de utilizare ale gRPC
- API-uri web
- Servicii web
- Aplicații de streaming
- Comunicarea microserviciilor
Asemănări între REST și gRPC
- Mecanism de schimb de date: ambele modele arhitecturale permit serverelor și clienților să facă schimb de date. Cu toate acestea, aceste date sunt partajate pe baza anumitor reguli.
- Potrivit pentru sisteme scalabile și distribuite: comunicarea asincronă și designul fără stat atât al REST, cât și al gRPC facilitează scalarea API-urilor lor.
- Utilizați comunicarea bazată pe HTTP: ambele folosesc HTTP, cel mai preferat protocol de comunicare de pe web.
- Flexibil: puteți utiliza REST și gRPC cu diferite limbaje și tehnologii de programare.
REST vs. gRPC: Deep Dive Comparație
Serviciile REST și gRPC diferă în următoarele moduri;
Schimb de date
În API-urile REST, datele transmise de la o componentă software la alta trebuie să fie exprimate în format JSON. JSON trebuie serializat și tradus într-un limbaj de programare pentru schimbul de date. Cu toate acestea, API-urile Rest pot face schimb de formate de date precum HTML și XML.
gRPC, în mod implicit, utilizează formatul Protocol Buffers. Cu toate acestea, acceptă și în mod nativ JSON. Tamponele de protocol nu pot fi citite de om. Serverul folosește limbajul de descriere a interfeței Protocol Buffer pentru a defini o structură de date. gPRC serializează apoi structura de date într-un format binar. Apoi va deserializa datele în orice limbaj de programare specificat.
Model de comunicare
În REST, un client trimite o singură cerere către un server; serverul trimite apoi un răspuns ca răspuns. Clientul trebuie să aștepte răspunsul serverului înainte de a continua operațiunile. Este un model cerere-răspuns.
În gRPC, un client poate trimite cereri de server unice sau multiple, rezultând răspunsuri unice sau, respectiv, multiple. Conexiunile de date pot fi multi-la-multi, multi-la-unu, unu-la-multi sau unu-la-unu. gRPC folosește un model de comunicare client-răspuns.
Generarea codului
gRPC are încorporate caracteristici native de generare a codului pe partea de server și pe partea clientului. Puteți găsi aceste caracteristici în diferite limbi datorită compilatorului Protocol Buffers. gRPC generează codul server-side și client-side după definirea structurii în fișierul proto.
REST nu are funcții încorporate de generare a codului. Dacă aveți nevoie de această funcție, puteți utiliza instrumente terțe.
Protocolul HTTP
API-urile REST folosesc HTTP 1.1. Pentru a trimite o solicitare pentru un serviciu REST, aveți nevoie de o adresă URL a resursei. HTTP 1 trimite informații între un computer și un server web. Adresa URL a resursei din serviciul REST este vizibilă pentru client. Designerii API controlează structura URL-urilor resurselor.
gRPC folosește HTTP 2. Această versiune HTTP a fost introdusă în 2015 și este folosită în browsere precum Internet Explorer, Safari și Chrome. Spre deosebire de HTTP 1, care păstrează totul în text simplu, acest format mai nou utilizează încapsularea în format binar, rezultând mai multe opțiuni de livrare a datelor și accelerând întregul proces.
Structura datelor de încărcare utilă
REST folosește XML sau JSON pentru a trimite și a primi date. JSON este cel mai folosit format pentru trimiterea de date dinamice în REST, deoarece este flexibil și nu necesită nicio structură. Datele JSON sunt, de asemenea, lizibile de către om. Singura problemă cu JSON nu este atât de rapidă, deoarece trebuie serializat și tradus în timpul transferului de date.
gRPC folosește Protocol Buffer-uri pentru a serializa datele de încărcare utilă. Acesta este un format foarte comprimat care reduce datele mesajelor. Acest cadru folosește Protobuf pentru a converti automat mesajele puternic tipizate în limbajele de programare ale clientului și serverului.
Suport pentru browser
REST este acceptat de toate browserele deoarece utilizează HTTP 1.1. Acest lucru îl face o alegere perfectă pentru serviciile web și API-uri.
gRPC are suport limitat pentru browsere, deoarece se bazează pe HTTP 2. Pentru a accepta toate browserele, trebuie să adăugați gRPC-web ca strat proxy. Din acest motiv, gRPC este adoptat în mare parte pentru sistemele interne.
Cuplare client-server
REST este un design arhitectural slab cuplat. Înseamnă că clientul și serverul nu trebuie să știe unul despre implementările celuilalt. Această caracteristică face mai ușoară evoluția unui API RESTful în timp, deoarece nu trebuie să modificați codul clientului atunci când modificați definițiile serverului.
gRPC este un cadru strâns cuplat în care serverul și clientul trebuie să aibă acces la același fișier proto. Dacă trebuie să faceți modificări fișierului, trebuie să actualizați și serverul și clientul.
Odihna vs. gRPC
Caracteristică Protocolul RESTgRPCHTTPHTTP 1.1HTTP 2Suport pentru browserSuportă toate browserele deoarece utilizează HTTP 1.1 Suport mai mic pentru browser deoarece utilizează HTTP 2Generarea coduluiFolosește instrumente terțe Caracteristici de generare a codului încorporate Abordare de proiectare Proiectare orientată către entitate Abordare orientată către servicii Acces la date Adresă URL de implementare a resurselor este necesar un apel de date nedisponibil. REST pe client sau pe server software-ul RPC este necesar atât pe partea client, cât și pe server. Model de comunicareUn singur client comunică cu un singur server. Modele de comunicare multiple, cum ar fi un client care trimite cereri către mai multe servere, un server care comunică cu mai mulți clienți sau un server care comunică cu un singur client.
Când să folosiți REST
API-urile RESTful și serviciile web sunt foarte populare. Serviciile RESTful sunt ușor de implementat, structurează datele, sunt flexibile și ușor de citit. Puteți utiliza REST în următoarele cazuri;
- Arhitecturi bazate pe web: puteți crea API-uri web, mobile și multiplatformă folosind designul arhitectural REST.
- Comunicații simple de date: REST utilizează JSON, un format de date ușor de citit.
- API-uri destinate publicului: dacă intenționați ca publicul să consume date și să utilizeze API-ul dvs., REST va fi o alegere bună datorită caracteristicii sale de lizibilitate.
Când să utilizați gRPC
gRPC nu este la fel de popular ca serviciile RESTful. Cu toate acestea, are și caracteristici unice care îl vor face să iasă în evidență în următoarele aplicații;
- Sisteme în mai multe limbi: gRPC se potrivește arhitecturilor de microservicii scrise în diferite limbaje de programare și în care API-ul este puțin probabil să se schimbe.
- Conexiuni la microservicii: caracteristici precum streaming bidirecțional și suport scăzut pentru browser fac din gRPC o alegere bună pentru API-urile interne.
- Rețele de streaming în timp real: puteți utiliza gRPC cu servicii interne care se ocupă de încărcări mari de date și necesită streaming în timp real.
Opinia autorilor
Chiar dacă gRPC are unele caracteristici specifice care pot depăși REST în aplicații precum Internetul lucrurilor, acesta din urmă câștigă datorită lizibilității, flexibilității și adoptării pe scară largă. Suportul mai scăzut de browser al gRPC îl face o alegere deloc bună pentru dezvoltatorii care doresc să creeze servicii web.
Suportul universal pentru serviciile RESTful face din REST stilul arhitectural API ideal pentru integrările web și microservicii.
Concluzie
REST și gRPC se numără printre numeroasele stiluri arhitecturale API pe care le puteți alege atunci când vă construiți următorul API. Alegerea finală va depinde de produsul pe care doriți să îl construiți. Serviciile RESTful se vor potrivi perfect atunci când construiesc API-uri destinate publicului, în timp ce gRPC este o alegere bună pentru servicii precum aplicațiile mobile care nu necesită suport pentru browser.
Apoi, consultați articolul nostru despre cum să creați gRPC de la zero folosind Java.