Share
REST API har vært en søyle for webprogrammering i lang tid. Men nylig har gRPC begynt å krysse på sitt territorium. Det viser seg at det er noen veldig gode grunner til det. I denne opplæringen lærer du om innspill og outs av gRPC og hvordan den sammenlignes med REST.
En av de største forskjellene mellom REST og gRPC er formatet på nyttelastet. REST meldinger inneholder vanligvis JSON. Dette er ikke et strengt krav, og i teorien kan du sende alt som et svar, men i praksis er hele REST-økosystemet - inkludert verktøy, beste praksis og opplæringsprogrammer - fokusert på JSON. Det er trygt å si at, med svært få unntak, godtar REST APIs og returnerer JSON.
gRPC, på den annen side aksepterer og returnerer Protobuf-meldinger. Jeg vil diskutere den sterke typen senere, men bare fra et ytelsessynspunkt er Protobuf et meget effektivt og pakket format. JSON, derimot, er et tekstformat. Du kan komprimere JSON, men da mister du fordelene ved et tekstformat som du enkelt kan forvente.
La oss sammenligne overføringsprotokollene som REST og gRPC bruker. REST, som tidligere nevnt, avhenger mye av HTTP (vanligvis HTTP 1.1) og forespørselsresponsmodellen. På den annen side bruker gRPC den nyere HTTP / 2-protokollen.
Det er flere problemer som plager HTTP 1.1 som HTTP / 2 retter. Her er de store.
HTTP 1.0 RFC 1945 er en 60-siders RFC. HTTP 1.1 ble opprinnelig beskrevet i RFC 2616, som ballongde opptil 176 sider. Imidlertid splittet IETF den opp i seks forskjellige dokumenter-RFC 7230, 7231, 7232, 7233, 7234 og 7235-med en enda høyere kombinert sidetall. HTTP 1.1 tillater mange valgfrie deler som bidrar til størrelsen og kompleksiteten.
Trenden på nettsider er å øke både den totale størrelsen på siden (1,9 MB i gjennomsnitt) og antall objekter på siden som krever individuelle forespørsler. Siden hvert objekt krever en separat HTTP-forespørsel, øker denne multipliseringen av separate objekter belastningen på webservere betydelig og reduserer sidelastningstider for brukere.
HTTP 1.1 er følsom for latens. Et TCP-håndtrykk er nødvendig for hver enkelt forespørsel, og større antall forespørsler tar en betydelig avgift på den tiden det trengs for å laste inn en side. Den løpende forbedringen i tilgjengelig båndbredde løser ikke disse latensproblemer i de fleste tilfeller.
Begrensningen på antall tilkoblinger til samme domene (pleide å være bare 2, i dag 6-8) reduserer signifikant muligheten til å sende flere forespørsler parallelt.
Med HTTP pipelining kan du sende en forespørsel mens du venter på svaret på en tidligere forespørsel, og skaper en kø. Men det introduserer andre problemer. Hvis forespørselen din blir sittende fast etter en sakte forespørsel, vil du svare på svaret ditt.
Det er andre bekymringer som ytelses- og ressursbøter ved bytte av linjer. For øyeblikket er ikke HTTP-rørledninger generelt aktivert.
HTTP / 2, som kom ut av Googles SPDY, opprettholder de grunnleggende premissene og paradigmene til HTTP:
Accentsconagua
http: // og https: // URL-skjemaerMen de valgfrie delene av HTTP 1.1 ble fjernet.
For å adressere forhandlingsprotokollen på grunn av det delte nettadresseskjemaet, er det en oppgraderingsoverskrift. Også her er en shocker for deg: HTTP / 2-protokollen er binær! Hvis du har vært i nærheten av internettprotokoller, vet du at tekstprotokoller regnes som konge fordi de er enklere for mennesker å feilsøke og konstruere forespørsler manuelt. Men i praksis bruker de fleste servere i dag kryptering og komprimering uansett. Binærrammen går langt i retning av å redusere kompleksiteten til håndteringsrammer i HTTP 1.1.
Den store forbedringen av HTTP / 2 er imidlertid at den bruker multiplexerte strømmer. En enkelt HTTP / 2 TCP-tilkobling kan støtte mange toveisstrømmer. Disse strømmene kan interleaved (ingen kø), og flere forespørsler kan sendes samtidig uten behov for å etablere nye TCP-tilkoblinger for hver enkelt. I tillegg kan servere nå sende meldinger til klienter via den etablerte forbindelsen (HTTP / 2 push).
REST er en interessant API. Den er bygget veldig tett på toppen av HTTP. Den bruker ikke bare HTTP som en transport, men omfatter alle dens funksjoner og bygger et konsistent konseptuelt rammeverk på toppen av det. I teorien høres det bra ut. I praksis har det vært svært vanskelig å implementere REST riktig.
Gjør meg ikke feil-REST har vært og er veldig vellykket, men de fleste implementeringer følger ikke helt REST-filosofien og bruker bare en del av prinsippene sine. Årsaken er at det faktisk er ganske utfordrende å kartlegge forretningslogikk og operasjoner i den strenge REST-verdenen.
Den konseptuelle modellen som brukes av gRPC, er å ha tjenester med klare grensesnitt og strukturerte meldinger til forespørsler og svar. Denne modellen oversetter direkte fra programmeringsspråkskonsepter som grensesnitt, funksjoner, metoder og datastrukturer. Det tillater også at gRPC automatisk genererer klientbiblioteker for deg.
REST støtter kun forespørselsresponsmodellen som er tilgjengelig i HTTP 1.x. Men gRPC drar full nytte av funksjonene til HTTP / 2, og lar deg streame informasjon hele tiden. Det er flere typer streaming.
Serveren sender tilbake en strøm av svar etter å ha mottatt en klientforespørselsmelding. Etter at alle svarene er sendt tilbake, blir serverens statusdetaljer og valgfrie etterfølgende metadata sendt tilbake for å fullføre på serverens side. Klienten fullføres når den har alle serverens svar.
Klienten sender en strøm av flere forespørsler til serveren. Serveren sender tilbake et enkelt svar, typisk, men ikke nødvendigvis etter at det har mottatt alle klientens forespørsler, sammen med statusinformasjonen og valgfrie etterfølgende metadata.
I dette scenariet sender klienten og serveren informasjon til hverandre i ganske mye fri form (bortsett fra at klienten initierer sekvensen). Til slutt lukker klienten tilkoblingen.
REST-paradigmet gjør ikke noen struktur for den utvekslede nyttelastet. Det er vanligvis JSON. Forbrukerne har ikke en formell mekanisme for å koordinere formatet av forespørsler og svar. JSON må være serialisert og konvertert til målprogrammeringsspråket både på serversiden og klientsiden. Serialisering er et annet skritt i kjeden som introduserer muligheten for feil og ytelse overhead.
GRPC-servicekontrakten har sterkt skrevet meldinger som automatisk konverteres fra deres Protobuf-representasjon til det valgte programmeringsspråket både på serveren og på klienten.
JSON, derimot, er teoretisk mer fleksibel fordi du kan sende dynamiske data og ikke behøver å følge en stiv struktur.
Støtte for gRPC i nettleseren er ikke like moden. I dag brukes gRPC primært til interne tjenester som ikke eksponeres direkte for verden.
Hvis du vil konsumere en gRPC-tjeneste fra et webprogram eller fra et språk som ikke støttes av gRPC, tilbyr gRPC en REST API-gateway for å avsløre tjenesten. GRPC gateway plugin genererer en fullverdig REST API-server med omvendt proxy og Swagger dokumentasjon.
Med denne tilnærmingen mister du de fleste fordelene med gRPC, men hvis du trenger å gi tilgang til en eksisterende tjeneste, kan du gjøre det uten å implementere tjenesten din to ganger.
I verden av microservices vil gRPC bli dominerende snart. Ytelsesfordelene og enkel utvikling er bare for gode til å passere. Men gjør ingen feil, REST vil fortsatt være rundt i lang tid. Det utmerker seg fortsatt for offentlig utsatte APIer og for bakoverkompatibilitet grunner.
