![Hvilken du skal vælge til dit næste projekt [2023]](https://toadmin.dk/wp-content/uploads/2023/08/Hvilken-du-skal-vaelge-til-dit-naeste-projekt-2023.jpg?v=1691400380)
Du vil ofte støde på REST og gRPC, når du har med API’er at gøre. Selvom Rest har domineret dette felt i mange år, viser gRPC sig at være en værdig konkurrent.
Rest og gPRC er to forskellige måder, du kan designe en API på. API’er fungerer som en kommunikationsbro mellem tjenester, der kan repræsentere komplekse systemer, der ligger på forskellige computere eller er skrevet på forskellige sprog.
Denne artikel introducerer både Rest og gRPC, deler deres ligheder, forskelle og hvor de skal bruge hver.
Indholdsfortegnelse
Hvad er hvile?
Hvile (Representational State Transfer) er en arkitektonisk softwaretilgang, der dikterer regler for, hvordan softwarekomponenter udveksler data. Resten er baseret på nettets standard kommunikationsprotokol, HTTP.
Alle API’er baseret på REST arkitektoniske stil kaldes RESTful API’er. På den anden side er webtjenester efter REST arkitektonisk design kendt som RESTful webtjenester.
REST arkitektoniske stil er styret af disse principper;
- Ensartet interface: Serveren skal overføre data i et standardformat. De transporterede data kan dog være i et andet format end den interne repræsentation af serverapplikationens ressource.
- Statsløshed: Serveren skal fuldføre hver klientanmodning uafhængigt, uanset de tidligere anmodninger. Kundeanmodninger om ressourcer kan være i enhver rækkefølge, og hver anmodning er isoleret fra resten.
- Lagdelt system: Præsenterer et lag af autoriserede mellemmænd mellem serveren og klienten. Klienten kan oprette forbindelse til disse autoriserede mellemmænd og stadig modtage svar fra serveren.
- Cachebarhed: Nogle svar gemmes på en mellemmand eller klienten for at forbedre responstiden.
- Kode efter behov: Servere tilpasser eller udvider midlertidigt klientfunktionaliteten ved at overføre softwareprogrammeringskode til klienten.
Fordele ved REST
- Skalerbar: REST API’er er kendt for deres skalerbarhed, da de optimerer klient-server-interaktioner. Caching og statsløshed er de vigtigste funktioner, der reducerer serverbelastningen.
- Fleksibel: RESTful API’er tilbyder total klient-server-adskillelse. Sådanne tjenester vil afkoble og forenkle forskellige serverkomponenter, som kan udvikle sig uafhængigt.
- Uafhængighed: Du kan skrive server- og klientapplikationer på forskellige programmeringssprog uden at påvirke API-designet.
Brug tilfælde af Rest
- Web API’er
- Webtjenester
- Mikroservices arkitektur
Hvad er gRPC?
gRPC er en RPC-ramme (Remote Procedure Call), der kan køre i ethvert miljø. Denne open source-ramme er designet som en højtydende protokol, der effektivt kan forbinde tjenester på tværs af og i datacentre.
En klientapp kan kalde en metode på en serverapp på en anden maskine, som om det var et lokalt objekt. Med gRPC definerer du en tjeneste og angiver de metoder, du kan kalde eksternt med deres parametre og returtyper.
gRPC har pluggbar sundhedstjek, godkendelse, belastningsbalancering og sporing. Denne ramme bruger HTTP 2 og protokolbuffere til datatransmission. Når data udveksles, kaldes en procedure i stedet for en ressource-URL
Fordele ved gRPC
- Skalerbar: gRPC giver dig mulighed for at installere runtime-miljøer med en enkelt kommando og begynde at skalere millioner af RPC’er/sekund.
- Simpel servicedefinition: Brug protokolbuffere til at definere dine tjenester og få dem til at køre.
- Cross-platform: Denne ramme genererer idiomatiske klient- og serverstubbe til forskellige platforme og sprog.
- Tovejs streaming og integreret godkendelse.
Brug tilfælde af gRPC
- Web API’er
- Webtjenester
- Streaming applikationer
- Mikroservices kommunikation
Ligheder mellem REST og gRPC
- Dataudvekslingsmekanisme: Begge arkitektoniske design tillader servere og klienter at udveksle data. Disse data deles dog ud fra visse regler.
- Velegnet til skalerbare og distribuerede systemer: Den asynkrone kommunikation og det statsløse design af både REST og gRPC gør det nemt at skalere deres API’er.
- Brug HTTP-baseret kommunikation: Begge bruger HTTP, den mest foretrukne kommunikationsprotokol på nettet.
- Fleksibel: Du kan bruge REST og gRPC med forskellige programmeringssprog og teknologier.
REST vs. gRPC: Deep Dive Comparison
REST- og gRPC-tjenester adskiller sig på følgende måder;
Dataudveksling
I REST API’er skal data, der overføres fra en softwarekomponent til en anden, udtrykkes i JSON-format. JSON skal serialiseres og oversættes til et programmeringssprog for dataudveksling. Rest API’er kan dog også udveksle dataformater som HTML og XML.
gRPC bruger som standard Protocol Buffers-formatet. Det understøtter dog også indbygget JSON. Protokolbuffere kan ikke læses af mennesker. Serveren bruger Protocol Buffer interface description sprog til at definere en datastruktur. gPRC serialiserer derefter datastrukturen til et binært format. Det vil derefter deserialisere dataene til ethvert specificeret programmeringssprog.
Kommunikationsmodel
I REST sender en klient en enkelt anmodning til en server; serveren sender derefter et svar som svar. Klienten skal vente på serverens svar, før han fortsætter driften. Det er en anmodning-svar-model.
I gRPC kan en klient sende enkelte eller flere serveranmodninger, hvilket resulterer i henholdsvis enkelte eller flere svar. Dataforbindelser kan være mange-til-mange, mange-til-en, én-til-mange eller én-til-én. gRPC bruger en klient-svar kommunikationsmodel.
Kodegenerering
gRPC har indbyggede native server-side og client-side kodegenereringsfunktioner. Du kan finde disse funktioner på forskellige sprog takket være kompilatoren Protocol Buffers. gRPC genererer server- og klientsidekoden efter at have defineret strukturen i protofilen.
REST mangler indbyggede kodegenereringsfunktioner. Hvis du har brug for denne funktion, kan du bruge tredjepartsværktøjer.
HTTP protokol
REST API’er bruger HTTP 1.1. For at sende en anmodning på en REST-tjeneste skal du bruge en ressource-URL. HTTP 1 sender information mellem en computer og en webserver. Ressource-URL’en i REST-tjenesten er synlig for klienten. API-designerne styrer strukturen af ressource-URL’er.
gRPC bruger HTTP 2. Denne HTTP-version blev introduceret i 2015 og bruges i browsere som Internet Explorer, Safari og Chrome. I modsætning til HTTP 1, som holder alt i almindelig tekst, bruger dette nyere format indkapsling af binært format, hvilket resulterer i flere muligheder for datalevering og fremskynder hele processen.
Datastruktur for nyttelast
REST bruger XML eller JSON til at sende og modtage data. JSON er det mest brugte format til at sende dynamiske data i REST, da det er fleksibelt og ikke kræver nogen struktur. JSON-data kan også læses af mennesker. Det eneste problem med JSON er ikke så hurtigt, da det skal serialiseres og oversættes under dataoverførsel.
gRPC bruger protokolbuffere til at serialisere nyttelastdata. Dette er et meget komprimeret format, der reducerer meddelelsernes data. Denne ramme bruger Protobuf til automatisk at konvertere stærkt indskrevne meddelelser til klientens og serverens programmeringssprog.
Browser support
REST understøttes på alle browsere, da den bruger HTTP 1.1. Dette gør det til et perfekt valg til webtjenester og API’er.
gRPC har begrænset understøttelse af browsere, da den er baseret på HTTP 2. For at understøtte alle browsere skal du tilføje gRPC-web som et proxy-lag. Af denne grund er gRPC for det meste brugt til interne systemer.
Klient-server kobling
REST er et løst koblet arkitektonisk design. Det betyder, at klienten og serveren ikke behøver at kende til hinandens implementeringer. Denne funktion gør det nemmere at udvikle en RESTful API over tid, da du ikke behøver at ændre klientkoden, når du ændrer serverdefinitioner.
gRPC er et tæt koblet framework, hvor serveren og klienten skal have adgang til den samme protofil. Hvis du skal foretage ændringer i filen, skal du også opdatere serveren og klienten.
Hvile vs. gRPC
FeatureRESTgRPCHTTP protokolHTTP 1.1HTTP 2Browserunderstøttelse Understøtter alle browsere, da den bruger HTTP 1.1 Mindre browserunderstøttelse, da den bruger HTTP 2KodegenereringBruger tredjepartsværktøjer Indbyggede kodegenereringsfunktionerDesigntilgang Entitetsorienteret designServiceorienteret tilgangDataadgangResource URLsServiceopkaldImplementeringVendirekteopkaldBidirekte-implementering. REST på klienten eller server-sidegRPC-software er nødvendig både på klient- og serversiden. KommunikationsmodelEn enkelt klient kommunikerer med en enkelt server.Flere kommunikationsmodeller som en klient sender anmodninger til flere servere, en server kommunikerer med flere klienter eller en server kommunikerer med en klient.
Hvornår skal man bruge REST
RESTful API’er og webtjenester er meget populære. RESTful-tjenester er nemme at implementere, strukturerer data, fleksible og læsbare. Du kan bruge REST i følgende tilfælde;
- Web-baserede arkitekturer: Du kan oprette web-, mobil- og multiplatform-API’er ved hjælp af REST-arkitektonisk design.
- Enkel datakommunikation: REST bruger JSON, et letlæseligt dataformat.
- Offentlige API’er: Hvis du har til hensigt, at offentligheden skal forbruge data og bruge din API, vil REST være et godt valg på grund af dens læsbarhedsfunktion.
Hvornår skal du bruge gRPC
gRPC er ikke så populær som RESTful-tjenester. Den har dog også unikke funktioner, der vil få den til at skille sig ud i følgende applikationer;
- Flersprogede systemer: gRPC passer til mikroservicearkitekturer skrevet på forskellige programmeringssprog, og hvor API’en sandsynligvis ikke ændrer sig.
- Mikroserviceforbindelser: Funktioner som tovejs streaming og lav browserunderstøttelse gør gRPC til et godt valg til interne API’er.
- Streaming-netværk i realtid: Du kan bruge gRPC med interne tjenester, der håndterer store databelastninger og kræver streaming i realtid.
Forfatternes mening
Selvom gRPC har nogle specifikke funktioner, der kan overskygge REST i applikationer som Internet of Things, vinder sidstnævnte på grund af dets læsbarhed, fleksibilitet og brede anvendelse. gRPC’s lavere browserunderstøttelse gør det til et knap så godt valg for udviklere, der ønsker at bygge webtjenester.
Den universelle understøttelse af RESTful-tjenester gør REST til den ideelle API-arkitektoniske stil til integrationer af web og mikrotjenester.
Konklusion
REST og gRPC er blandt de mange API-arkitektoniske stilarter, du kan vælge, når du bygger din næste API. Det endelige valg afhænger af det produkt, du vil bygge. RESTful-tjenester vil være en perfekt pasform, når du bygger offentlige API’er, mens gRPC er et godt valg til tjenester som mobilapplikationer, der ikke kræver browserunderstøttelse.
Se derefter vores artikel om, hvordan du opretter gRPC fra bunden ved hjælp af Java.
