När man arbetar med API:er stöter man ofta på termerna REST och gRPC. Även om REST länge varit det dominerande valet, har gRPC framstått som en stark konkurrent.
Både REST och gRPC representerar olika metoder för att designa ett API. API:er fungerar som en kommunikationslänk mellan olika tjänster, vilka kan utgöra komplexa system spridda över olika datorer eller skrivna i olika programmeringsspråk.
Denna artikel ger en introduktion till både REST och gRPC, undersöker deras likheter och skillnader samt ger vägledning om när de bör användas.
Vad är REST?
REST, eller Representational State Transfer, är en arkitektonisk strategi för mjukvara som fastställer regler för hur programvarukomponenter utbyter information. REST bygger på webbens standardprotokoll för kommunikation, HTTP.
Ett API som konstruerats i enlighet med REST-arkitekturen kallas ett RESTful API. På motsvarande sätt benämns webbtjänster som följer REST-designen som RESTful webbtjänster.
REST-arkitekturen styrs av följande principer:
- Enhetligt gränssnitt: Servern ska skicka data i ett standardiserat format. Dataformatet kan dock skilja sig från hur serverapplikationens resurs representeras internt.
- Tillståndslöshet: Varje klientförfrågan ska behandlas oberoende av servern, utan hänsyn till tidigare förfrågningar. Resursförfrågningar från klienter kan ske i godtycklig ordning, och varje förfrågan är isolerad.
- Skiktat system: Ett lager av auktoriserade mellanhänder placeras mellan servern och klienten. Klienten kan ansluta till dessa mellanhänder och ändå få svar från servern.
- Möjlighet till cachelagring: Vissa svar kan sparas i en mellanhand eller klient för att förbättra svarstiden.
- Kod på begäran: Servrar kan tillfälligt anpassa eller utöka klientens funktioner genom att skicka programvarukod till klienten.
Fördelar med REST
- Skalbarhet: REST API:er är kända för sin skalbarhet, vilket uppnås genom optimerade klient-server-interaktioner. Cachelagring och tillståndslöshet är centrala funktioner som minskar belastningen på servern.
- Flexibilitet: RESTful API:er erbjuder en tydlig separation mellan klient och server. Sådana tjänster möjliggör frikoppling och underlättar utvecklingen av olika serverkomponenter oberoende av varandra.
- Oberoende: Server- och klientapplikationer kan utvecklas i olika programmeringsspråk utan att API-designen påverkas.
Användningsområden för REST
- Webb-API:er
- Webbtjänster
- Mikrotjänstarkitektur
Vad är gRPC?
gRPC är ett ramverk för Remote Procedure Call (RPC) som kan användas i alla typer av miljöer. Detta öppen källkod-ramverk är utformat som ett högpresterande protokoll för att effektivt ansluta tjänster inom och mellan datacenter.
En klientapplikation kan anropa en metod i en serverapplikation på en annan dator som om det vore ett lokalt objekt. Med gRPC definierar man en tjänst och specificerar metoder som kan anropas på distans, tillsammans med deras parametrar och returtyper.
gRPC har inbyggt stöd för hälsokontroller, autentisering, lastbalansering och spårning. Ramverket använder HTTP/2 och Protocol Buffers för dataöverföring. Istället för att referera till en resurs-URL, anropas en procedur vid datautbyte.
Fördelar med gRPC
- Skalbarhet: Med gRPC kan du konfigurera körmiljöer med ett enkelt kommando och skala upp till miljontals RPC:er per sekund.
- Enkel tjänstdefinition: Definiera tjänster med Protocol Buffers och implementera dem direkt.
- Plattformsoberoende: Ramverket genererar klient- och serverstubbar på olika plattformar och språk.
- Dubbelriktad streaming och integrerad autentisering är tillgängliga.
Användningsområden för gRPC
- Webb-API:er
- Webbtjänster
- Streamingapplikationer
- Mikrotjänstkommunikation
Likheter mellan REST och gRPC
- Datautbytesmekanism: Båda arkitekturerna gör det möjligt för servrar och klienter att kommunicera genom datautbyte, men inom ramen för specifika regler.
- Lämplighet för skalbara och distribuerade system: Den asynkrona kommunikationen och tillståndslösheten i både REST och gRPC underlättar skalbarheten av API:er.
- Användning av HTTP-baserad kommunikation: Båda använder HTTP, det mest vanliga kommunikationsprotokollet på webben.
- Flexibilitet: REST och gRPC kan användas med olika programmeringsspråk och tekniker.
REST vs. gRPC: En djupgående jämförelse
REST- och gRPC-tjänster skiljer sig på följande sätt:
Datautbyte
I REST API:er måste data som skickas mellan programvarukomponenter vanligtvis uttryckas i JSON-format. JSON måste serialiseras och omvandlas till ett programmeringsspråk för datautbyte. REST API:er kan dock även hantera data i format som HTML och XML.
gRPC använder Protocol Buffers som standardformat, men stöder även JSON. Protocol Buffers är inte läsbara för människor. Servern använder Protocol Buffer-gränssnittets beskrivningsspråk för att definiera en datastruktur. gRPC serialiserar sedan datastrukturen till ett binärt format och deserialiserar det sedan till valfritt programmeringsspråk.
Kommunikationsmodell
I REST skickar klienten en enkel förfrågan till en server som svarar. Klienten måste vänta på serverns svar innan operationen kan fortsätta. Det är en begäran-svar-modell.
gRPC möjliggör för en klient att skicka en eller flera förfrågningar till servern, vilket kan resultera i en eller flera svar. Dataanslutningar kan vara en-till-en, en-till-många, många-till-en eller många-till-många. gRPC använder en klient-server kommunikationsmodell.
Kodgenerering
gRPC har inbyggda funktioner för att generera kod på både server- och klientsidan. Dessa funktioner finns tillgängliga på olika språk via kompilatorn för Protocol Buffers. gRPC genererar kod efter att strukturen definierats i protofilen.
REST saknar inbyggda funktioner för kodgenerering, men man kan använda verktyg från tredje part.
HTTP-protokoll
REST API:er använder HTTP/1.1. För att skicka en begäran till en REST-tjänst behövs en resurs-URL. HTTP/1 hanterar informationsöverföring mellan en dator och en webbserver. Resurs-URL:en i en REST-tjänst är synlig för klienten, och API-utvecklare definierar strukturen för dessa URL:er.
gRPC använder HTTP/2. Denna version av HTTP introducerades 2015 och används i webbläsare som Internet Explorer, Safari och Chrome. Till skillnad från HTTP/1 som hanterar all information i klartext, använder HTTP/2 binär inkapsling, vilket ger fler alternativ för dataöverföring och ökar hastigheten.
Nyttolastdatastruktur
REST använder XML eller JSON för att skicka och ta emot data. JSON är det vanligaste formatet för dynamisk data i REST, eftersom det är flexibelt och inte kräver en fast struktur. JSON-data är också läsbara för människor. Den enda nackdelen med JSON är att serialisering och omvandling av data kan vara långsamt.
gRPC använder Protocol Buffers för att serialisera nyttolastdata. Det är ett komprimerat format som minskar meddelandenas storlek. Ramverket använder Protobuf för att automatiskt konvertera starkt typade meddelanden till det programmeringsspråk som klienten och servern använder.
Webbläsarstöd
REST har stöd i alla webbläsare eftersom det använder HTTP/1.1. Detta gör det till ett bra alternativ för webbtjänster och API:er.
gRPC har begränsat stöd för webbläsare eftersom det bygger på HTTP/2. För att stödja alla webbläsare krävs ett proxylager i form av gRPC-web. Därför används gRPC mestadels för interna system.
Klient-server-koppling
REST är en löst kopplad arkitektur, vilket betyder att klienten och servern inte behöver känna till varandras implementation. Detta gör det lättare att utveckla ett RESTful API över tid, eftersom klientkoden inte behöver ändras om serverdefinitioner ändras.
gRPC är ett tätt kopplat ramverk där servern och klienten måste ha tillgång till samma protofil. Om ändringar görs i filen, måste de också implementeras i både servern och klienten.
REST kontra gRPC
| Funktion | REST | gRPC |
| HTTP-protokoll | HTTP/1.1 | HTTP/2 |
| Webbläsarstöd | Stödjer alla webbläsare eftersom det använder HTTP/1.1 | Mindre stöd i webbläsare eftersom det använder HTTP/2 |
| Kodgenerering | Använder verktyg från tredje part | Inbyggda kodgenereringsfunktioner |
| Designmetod | Entitetsorienterad design | Tjänsteorienterad approach |
| Dataåtkomst | Resurs-URL:er | Tjänsteanrop |
| Programvara krävs för implementering | Ingen specifik programvara krävs, REST kan implementeras på klient- och serversidan | gRPC-programvara krävs på både klient- och serversidan. |
| Kommunikationsmodell | En klient kommunicerar med en server | Flera modeller, en klient kan kommunicera med flera servrar, en server med flera klienter eller en server 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. REST kan användas i följande fall:
- Webbaserade arkitekturer: Skapa API:er för webb-, mobil- och multiplattformsapplikationer med REST-arkitekturen.
- Enkel datakommunikation: REST använder JSON, ett lättläst dataformat.
- Offentliga API:er: Om data och API ska konsumeras av allmänheten, är REST ett bra val tack vare läsbarheten.
När ska gRPC användas
gRPC är inte lika vanligt som RESTful-tjänster, men det har unika egenskaper som gör det framträdande i följande applikationer:
- Flerspråkiga system: gRPC är lämpligt för mikrotjänstarkitekturer skrivna i olika programmeringsspråk, där API:et inte väntas förändras.
- Mikrotjänstkommunikation: Funktioner som dubbelriktad streaming och begränsat webbläsarstöd gör gRPC till ett bra val för interna API:er.
- Strömningsnätverk i realtid: gRPC kan användas med interna tjänster som hanterar stora datamängder och kräver realtidsströmning.
Författarens åsikt
Även om gRPC har specifika funktioner som kan vara bättre än REST i applikationer som Internet of Things, vinner REST tack vare läsbarhet, flexibilitet och breda användning. gRPC:s begränsade webbläsarstöd gör det till ett mindre bra val för utvecklare som vill skapa webbtjänster.
Det universella stödet för RESTful-tjänster gör REST till det perfekta valet för integrationer i webb- och mikrotjänster.
Slutsats
REST och gRPC är två bland många API-arkitekturer som kan väljas för nästa API. Det slutgiltiga valet beror på vilken produkt man vill skapa. RESTful-tjänster är ett idealiskt val för publika API:er, medan gRPC passar bra för mobila applikationer som inte kräver webbläsarstöd.
Läs gärna vår artikel om hur du skapar gRPC från grunden med Java.