Share
REST API har länge varit en pelare för webbprogrammering. Men nyligen har gRPC börjat inkräkta på sitt territorium. Det visar sig att det finns några väldigt bra skäl till det. I denna handledning lär du dig information om inlägg och utgåvor av gRPC och hur det jämförs med REST.
En av de största skillnaderna mellan REST och gRPC är nyttolastets format. REST-meddelanden innehåller vanligen JSON. Detta är inte ett strikt krav, och i teorin kan du skicka allt som ett svar, men i praktiken är hela REST-ekosystemet - inklusive verktyg, bästa praxis och handledning - inriktad på JSON. Det är säkert att säga att, med väldigt få undantag, accepterar REST APIs och returnerar JSON.
gRPC accepterar å andra sidan och returnerar Protobuf-meddelanden. Jag kommer att diskutera den starka skrivningen senare, men bara från en prestationssynvinkel är Protobuf ett mycket effektivt och packat format. JSON är å andra sidan ett textformat. Du kan komprimera JSON, men då förlorar du fördelen med ett textformat som du lätt kan förvänta dig.
Låt oss jämföra överföringsprotokoll som REST och gRPC använder. REST, som tidigare nämnts, beror starkt på HTTP (vanligtvis HTTP 1.1) och begäran-responsmodellen. Å andra sidan använder gRPC det nyare HTTP / 2-protokollet.
Det finns flera problem som plågar HTTP 1.1 som HTTP / 2 åtgärdar. Här är de stora.
HTTP 1.0 RFC 1945 är en 60-sidig RFC. HTTP 1.1 beskrevs ursprungligen i RFC 2616, som ballongde upp till 176 sidor. Men senare splittrade IETF upp i sex olika dokument-RFC 7230, 7231, 7232, 7233, 7234 och 7235-med en jämn högre kombinerad sidräkning. HTTP 1.1 möjliggör många frivilliga delar som bidrar till dess storlek och komplexitet.
Trenden på webbsidor är att öka både sidans totala storlek (1,9 MB i genomsnitt) och antalet objekt på sidan som kräver enskilda önskemål. Eftersom varje objekt kräver en separat HTTP-begäran, ökar denna multiplikation av separata objekt väsentligt på webservrar och saktar sidlastningstider för användare.
HTTP 1.1 är känslig för latens. Ett TCP-handslag krävs för varje enskild begäran, och större antal förfrågningar tar en väsentlig vägtull vid den tid som behövs för att ladda en sida. Den löpande förbättringen av tillgänglig bandbredd löser inte i de flesta fall dessa latensproblem.
Begränsningen av antalet anslutningar till samma domän (brukade vara bara 2, idag 6-8) minskar avsevärt möjligheten att skicka flera förfrågningar parallellt.
Med HTTP-pipelining kan du skicka en förfrågan medan du väntar på svaret på en tidigare förfrågan, vilket effektivt skapar en kö. Men det introducerar andra problem. Om din förfrågan fastnar bakom en långsam förfrågan kommer din svarstid att drabbas.
Det finns andra problem som prestations- och resursböter vid byte av linjer. För närvarande är HTTP-pipelining inte allmänt aktiverad.
HTTP / 2, som kom ut ur Googles SPDY, behåller de grundläggande förutsättningarna och paradigmerna för HTTP:
Accentsconagua
http: // och https: // URL schemanMen de valfria delarna av HTTP 1.1 avlägsnades.
För att hantera förhandlingsprotokollet på grund av det delade webbadressschemat finns en uppgraderingsrubrik. Här är också en chocker för dig: HTTP / 2-protokollet är binärt! Om du har funnit internetprotokoll vet du att textprotokoll anses vara kung eftersom de är enklare för människor att felsöka och konstruera förfrågningar manuellt. Men i praktiken använder de flesta servrar idag kryptering och komprimering i alla fall. Den binära inramningen går långt för att minska komplexiteten hos hanteringsramar i HTTP 1.1.
Den stora förbättringen av HTTP / 2 är dock att den använder multiplexerade strömmar. En enda HTTP / 2 TCP-anslutning kan stödja många dubbelriktade flöden. Dessa strömmar kan interfolieras (ingen köning), och flera förfrågningar kan skickas samtidigt utan att det behövs nya TCP-anslutningar för var och en. Dessutom kan servrar nu trycka meddelanden till kunder via den etablerade anslutningen (HTTP / 2-push).
REST är ett intressant API. Den är byggd väldigt tätt ovanpå HTTP. Den använder inte bara HTTP som en transport, men omfattar alla dess funktioner och bygger en konsekvent konceptuell ram ovanpå. I teorin låter det bra. I praktiken har det varit mycket svårt att genomföra REST korrekt.
Får mig inte fel-REST har varit och är mycket framgångsrik, men de flesta implementationer följer inte helt REST-filosofin och använder endast en delmängd av sina principer. Anledningen är att det faktiskt är ganska utmanande att kartlägga affärslogik och verksamheter i den strikta REST-världen.
Den konceptuella modellen som används av gRPC är att ha tjänster med tydliga gränssnitt och strukturerade meddelanden för förfrågningar och svar. Denna modell översätts direkt från programmeringsspråkskoncept som gränssnitt, funktioner, metoder och datastrukturer. Det tillåter också att gRPC automatiskt genererar kundbibliotek för dig.
REST stöder endast den begäran-svarsmodell som finns tillgänglig i HTTP 1.x. Men gRPC utnyttjar fullt ut HTTP / 2: s möjligheter och låter dig strömma information hela tiden. Det finns flera typer av streaming.
Servern skickar tillbaka en ström av svar efter att ha fått ett klientförfrågningsmeddelande. Efter att ha skickat tillbaka alla sina svar skickas serverns statusuppgifter och eventuella efterföljande metadata tillbaka för att slutföra på serverns sida. Klienten slutförs när den har alla serverns svar.
Klienten skickar en ström av flera förfrågningar till servern. Servern skickar tillbaka ett enda svar, vanligtvis men inte nödvändigtvis efter att det har mottagit alla klientens förfrågningar, tillsammans med statusinformation och valfria efterföljande metadata.
I detta scenario skickar klienten och servern information till varandra i ganska mycket fri form (förutom att klienten initierar sekvensen). Så småningom stänger klienten anslutningen.
REST-paradigmet innebär inte någon struktur för den utbytta nyttolasten. Det är vanligtvis JSON. Konsumenterna har inte en formell mekanism för att samordna formatet för förfrågningar och svar. JSON måste serialiseras och omvandlas till målprogrammeringsspråket både på serverns och klientsidan. Serialiseringen är ett annat steg i kedjan som introducerar risken för fel såväl som prestationskostnader.
GRPC-tjänstekontraktet har starkt skrivit meddelanden som automatiskt konverteras från deras Protobuf-representation till ditt programmerade språk både på servern och på klienten.
JSON är å andra sidan teoretiskt mer flexibel eftersom du kan skicka dynamiska data och inte behöver hålla fast vid en styv struktur.
Stöd för gRPC i webbläsaren är inte lika mogen. Idag används gRPC främst för interna tjänster som inte utsätts direkt för världen.
Om du vill konsumera en gRPC-tjänst från ett webbprogram eller från ett språk som inte stöds av gRPC, erbjuder gRPC en REST API-gateway för att avslöja din tjänst. GRPC-gateway-plugin genererar en fullfjädrad REST API-server med omvänd proxy och Swagger dokumentation.
Med detta tillvägagångssätt förlorar du de flesta fördelarna med gRPC, men om du behöver ge tillgång till en befintlig tjänst kan du göra det utan att implementera din tjänst två gånger.
I microservices värld kommer gRPC att bli dominerande snart. Prestandafördelarna och utvecklingslättnaden är bara för bra att passera. Men gör inget misstag, REST kommer fortfarande att vara kvar länge. Det utmärker fortfarande för offentligt utsatta API och för bakåtkompatibilitetsskäl.
