Vilket du ska välja för ditt nästa projekt [2023]

Du kommer ofta att stöta på REST och gRPC när du har att göra med API:er. Även om Rest har dominerat detta område i många år har gRPC visat sig vara en värdig konkurrent.

Rest och gPRC är två olika sätt att designa ett API. API:er fungerar som en kommunikationsbrygga mellan tjänster som kan representera komplexa system som finns på olika datorer eller skrivna på olika språk.

Den här artikeln kommer att introducera både Rest och gRPC, dela deras likheter, skillnader och var de ska användas.

Vad är vila?

Resten (Representational State Transfer) är en arkitektonisk mjukvaruansats som dikterar regler för hur programvarukomponenter utbyter data. Vila baseras på webbens standardkommunikationsprotokoll, HTTP.

Alla API:er baserade på REST-arkitektoniska stilen kallas RESTful API:er. Å andra sidan är webbtjänster som följer REST arkitektonisk design kända som RESTful webbtjänster.

REST arkitektonisk stil styrs av dessa principer;

  • Enhetligt gränssnitt: Servern ska överföra data i ett standardformat. Data som transporteras kan dock vara i ett annat format än den interna representationen av serverapplikationens resurs.
  • Statslöshet: Servern ska slutföra varje klientförfrågan oberoende, oavsett tidigare begäranden. Klientförfrågningar om resurser kan vara i valfri ordning, och varje begäran är isolerad från resten.
  • Layered system: Presenterar ett lager av auktoriserade mellanhänder mellan servern och klienten. Klienten kan ansluta till dessa auktoriserade mellanhänder och fortfarande få svar från servern.
  • Cachebarhet: Vissa svar lagras på en mellanhand eller klienten för att förbättra svarstiden.
  • Kod på begäran: Servrar anpassar eller utökar tillfälligt klientfunktionaliteten genom att överföra programvaruprogrammeringskod till klienten.

Fördelar med REST

  • Skalbar: REST API: er är kända för sin skalbarhet eftersom de optimerar klient-server-interaktioner. Cachning och tillståndslöshet är de viktigaste funktionerna som minskar serverbelastningen.
  • Flexibel: RESTful API:er erbjuder total klient-serverseparation. Sådana tjänster kommer att frikoppla och förenkla olika serverkomponenter, som kan utvecklas oberoende av varandra.
  • Oberoende: Du kan skriva server- och klientapplikationer på olika programmeringsspråk utan att påverka API-designen.

Använd fall av vila

  • Webb-API:er
  • webbservice
  • Mikrotjänster arkitektur

Vad är gRPC?

gRPC är ett ramverk för Remote Procedure Call (RPC) som kan köras i alla miljöer. Detta ramverk med öppen källkod är designat som ett högpresterande protokoll som effektivt kan ansluta tjänster över och i datacenter.

En klientapp kan anropa en metod på en serverapp på en annan dator som om det vore ett lokalt objekt. Med gRPC definierar du en tjänst och specificerar metoderna du kan anropa på distans med deras parametrar och returtyper.

gRPC har pluggbar hälsokontroll, autentisering, lastbalansering och spårningsstöd. Detta ramverk använder HTTP 2 och Protocol Buffers för dataöverföring. När data utbyts anropas en procedur istället för en resurs-URL

Fördelar med gRPC

  • Skalbar: gRPC låter dig installera runtime-miljöer med ett enda kommando och börja skala miljontals RPC:er/sekund.
  • Enkel tjänstdefinition: Använd Protocol Buffers för att definiera dina tjänster och få dem att köra.
  • Cross-platform: Detta ramverk genererar idiomatiska klient- och serverstubbar för olika plattformar och språk.
  • Dubbelriktad streaming och integrerad autentisering.

Användningsfall av gRPC

  • Webb-API:er
  • webbservice
  • Streamingapplikationer
  • Mikrotjänster kommunikation

Likheter mellan REST och gRPC

  • Datautbytesmekanism: Båda arkitektoniska designerna tillåter servrar och klienter att utbyta data. Dessa data delas dock utifrån vissa regler.
  • Lämplig för skalbara och distribuerade system: Den asynkrona kommunikationen och tillståndslösa designen av både REST och gRPC gör det enkelt att skala sina API:er.
  • Använd HTTP-baserad kommunikation: Båda använder HTTP, det mest föredragna kommunikationsprotokollet på webben.
  • Flexibel: Du kan använda REST och gRPC med olika programmeringsspråk och teknologier.

REST vs. gRPC: Deep Dive Comparison

REST- och gRPC-tjänsterna skiljer sig åt på följande sätt;

Datautbyte

I REST API:er måste data som skickas från en programvarukomponent till en annan uttryckas i JSON-format. JSON måste serialiseras och översättas till ett programmeringsspråk för datautbyte. Men Rest API:er kan också utbyta dataformat som HTML och XML.

gRPC använder som standard formatet Protocol Buffers. Men den stöder också JSON. Protokollbuffertar är inte läsbara för människor. Servern använder Protocol Buffer-gränssnittets beskrivningsspråk för att definiera en datastruktur. gPRC serialiserar sedan datastrukturen till ett binärt format. Den kommer sedan att deserialisera data till alla specificerade programmeringsspråk.

Kommunikationsmodell

I REST skickar en klient en enda begäran till en server; servern skickar sedan ett svar som svar. Klienten måste vänta på serverns svar innan driften kan fortsätta. Det är en begäran-svar-modell.

I gRPC kan en klient skicka enstaka eller flera serverförfrågningar, vilket resulterar i enstaka eller flera svar, respektive. Dataanslutningar kan vara många-till-många, många-till-en, en-till-många eller en-till-en. gRPC använder en klient-svar kommunikationsmodell.

Kodgenerering

gRPC har inbyggda funktioner för kodgenerering på serversidan och klientsidan. Du kan hitta dessa funktioner på olika språk med tillstånd av kompilatorn för Protocol Buffers. gRPC genererar serversidan och klientsidans kod efter att ha definierat strukturen i protofilen.

REST saknar inbyggda kodgenereringsfunktioner. Om du behöver den här funktionen kan du använda verktyg från tredje part.

HTTP-protokoll

REST API:er använder HTTP 1.1. För att skicka en begäran på en REST-tjänst behöver du en resurs-URL. HTTP 1 skickar information mellan en dator och en webbserver. Resurs-URLen i REST-tjänsten är synlig för klienten. API-designerna kontrollerar strukturen för resurs-URL:erna.

gRPC använder HTTP 2. Denna HTTP-version introducerades 2015 och används i webbläsare som Internet Explorer, Safari och Chrome. Till skillnad från HTTP 1, som håller allt i vanlig text, använder detta nyare format inkapsling av binärt format, vilket resulterar i fler alternativ för dataleverans och påskyndar hela processen.

Nyttolastdatastruktur

REST använder XML eller JSON för att skicka och ta emot data. JSON är det mest använda formatet för att skicka dynamisk data i REST eftersom det är flexibelt och inte kräver någon struktur. JSON-data är också läsbara för människor. Det enda problemet med JSON är inte så snabbt eftersom det måste serialiseras och översättas under dataöverföring.

gRPC använder Protocol Buffers för att serialisera nyttolastdata. Detta är ett mycket komprimerat format som minskar meddelandenas data. Detta ramverk använder Protobuf för att automatiskt konvertera starkt skrivna meddelanden till klientens och serverns programmeringsspråk.

Webbläsarstöd

REST stöds i alla webbläsare eftersom den använder HTTP 1.1. Detta gör det till ett perfekt val för webbtjänster och API:er.

gRPC har begränsat stöd för webbläsare då det är baserat på HTTP 2. För att stödja alla webbläsare måste du lägga till gRPC-web som ett proxylager. Av denna anledning används gRPC mestadels för interna system.

Klient-server-koppling

REST är en löst kopplad arkitektonisk design. Det betyder att klienten och servern inte behöver känna till varandras implementeringar. Den här funktionen gör det lättare att utveckla ett RESTful API över tiden, eftersom du inte behöver ändra klientkoden när du ändrar serverdefinitioner.

gRPC är ett tätt kopplat ramverk där servern och klienten måste ha tillgång till samma protofil. Om du behöver göra några ändringar i filen måste du också uppdatera servern och klienten.

Vila kontra gRPC

FeatureRESTgRPCHTTP-protokollHTTP 1.1HTTP 2Webbläsarstöd Stödjer alla webbläsare eftersom det använder HTTP 1.1 Mindre webbläsarstöd eftersom det använder HTTP 2KodgenereringAnvänder verktyg från tredje part Inbyggda kodgenereringsfunktionerDesignmetode Entitetsorienterad designServiceorienterad tillvägagångssättDataåtkomstResurs-URLsServiceanropUndirigerbarmjukvara krävsimplementeringAnailprogramvaraImplementera REST på klienten eller server-sidegRPC programvara behövs både på klient- och serversidan. KommunikationsmodellEn enskild klient kommunicerar med en enda server Flera kommunikationsmodeller som att en klient skickar förfrågningar till flera servrar, en server som kommunicerar med flera klienter eller en server som kommunicerar med en klient.

När ska REST användas

RESTful API:er och webbtjänster är mycket populära. RESTful tjänster är lätta att implementera, strukturera data, flexibla och läsbara. Du kan använda REST i följande fall;

  • Webbaserade arkitekturer: Du kan skapa webb-, mobil- och multiplattforms-API:er med REST-arkitektonisk design.
  • Enkel datakommunikation: REST använder JSON, ett lättläst dataformat.
  • Offentliga API:er: Om du avser att allmänheten ska konsumera data och använda ditt API, kommer REST att vara ett bra val på grund av dess läsbarhetsfunktion.

När ska du använda gRPC

gRPC är inte lika populärt som RESTful-tjänster. Den har dock också unika egenskaper som gör att den sticker ut i följande applikationer;

  • Flerspråkiga system: gRPC passar mikrotjänstarkitekturer skrivna på olika programmeringsspråk och där API:et sannolikt inte kommer att förändras.
  • Mikroserviceanslutningar: Funktioner som dubbelriktad streaming och lågt webbläsarstöd gör gRPC till ett bra val för interna API:er.
  • Strömningsnätverk i realtid: Du kan använda gRPC med interna tjänster som hanterar stora databelastningar och kräver strömning i realtid.

Författarnas åsikt

Även om gRPC har vissa specifika funktioner som kan överglänsa REST i applikationer som Internet of Things, vinner det senare på grund av dess läsbarhet, flexibilitet och breda användning. gRPC:s lägre webbläsarstöd gör det till ett inte så bra val för utvecklare som vill bygga webbtjänster.

Det universella stödet för RESTful-tjänster gör REST till den idealiska API-arkitektoniska stilen för webb- och mikrotjänsterintegrationer.

Slutsats

REST och gRPC är bland de många API-arkitektoniska stilar du kan välja när du bygger ditt nästa API. Det slutliga valet beror på produkten du vill bygga. RESTful-tjänster kommer att passa perfekt när man bygger publika API:er, medan gRPC är ett bra val för tjänster som mobilapplikationer som inte kräver webbläsarstöd.

Kolla sedan in vår artikel om hur du skapar gRPC från början med Java.