U hebt wellicht woorden als REST horen vallen als het gaat om softwareontwikkeling. REST is een zeer algemeen gebruikte API-architectuur, en ontwikkelaars maken er veelvuldig gebruik van om software-API's te ontwerpen. Application programming interfaces zijn essentieel voor elke softwaretoepassing, en REST is een van de vele architecturen die voor API's worden gebruikt.
Tegenwoordig, gRPC architectuur wint aan populariteit, en ze beweert ook enkele problemen op te lossen die traditioneel worden geassocieerd met REST API's. Maar waarin verschillen ze? En welke moet u gebruiken voor uw toepassing? Om het antwoord op deze vragen te weten, moeten we meer begrijpen over gRPC versus REST en in welke scenario's ze beter presteren. Maar voordat we daar op ingaan, laten we eens kijken naar wat API's zijn en wat ze opleveren voor microservices.
Wat is een API?
Software-apps kunnen met elkaar communiceren door middel van application programming interfaces - API's, die functioneren als technische bemiddelaars. Een API is belast met het verzenden van een verzoek van een gebruiker naar het systeem, dat vervolgens een antwoord ontvangt van het systeem.
Stel je voor dat je online een telefoon bestelt. Je gaat naar een site die gekoppeld is aan het web, en die stuurt informatie over je verzoek naar een server. De server krijgt dan de informatie, analyseert ze, en antwoordt ons, na de nodige stappen te hebben ondernomen, met de details die op ons scherm verschijnen. Dit wordt mogelijk met API's.
De API schetst hoe dergelijke client requests moeten worden uitgevoerd, welke datastructuren moeten worden gebruikt, en aan welke standaarden clients zich moeten houden. Hij beschrijft ook de soorten queries die een programma naar een ander programma kan sturen. Beide gRPC vs REST architectuurstijlen worden veel gebruikt voor het ontwerpen van API's.
API's en microservices
Toepassingen kunnen een monolithische architectuur hebben of een microservice-architectuur. In een monolithische toepassing zitten alle functies en modules van de software in één enkele eenheid of codebase. Een microservice-applicatie daarentegen bestaat uit talrijke kleinere eenheden die met elkaar interageren via interfaces zoals het HTTP-protocol.
Het grootste probleem met de monolithische stijl is dat het moeilijker wordt om het systeem te veranderen, bij te werken en uit te breiden, naarmate ingenieurs nieuwe functies en diensten toevoegen aan het reeds bestaande fundament. Een verandering aan één aspect van de applicatie kan een nadelig effect hebben op andere onderdelen. De code van een monoliet raakt geleidelijk aan zo verstrengeld en moeilijk te doorgronden na vele malen geschaald, bijgewerkt en gewijzigd te zijn, dat een volledig herontwerp van het systeem nodig is.
Dit probleem wordt opgelost met microservices. Dit architectuurontwerp verdeelt een monoliet in zijn samenstellende componenten, die vervolgens elk als een afzonderlijke toepassing worden uitgevoerd. Elk van deze apps wordt een microservice genoemd. Vervolgens verbinden deze afzonderlijke microservices zich door middel van API's. Deze verzameling microservices die door API's met elkaar verbonden zijn, komen samen tot een groter architectuurontwerp. API's maken verbinding en communicatie mogelijk tussen elk onderdeel van een microservice-architectuur. Enkele populaire benaderingen voor het creëren van API's zijn GraphQL, RPC, en REST.
Wat is RPC?
Een RPC - Remote Procedure Call - is een webarchitectuur die het mogelijk maakt een dienst op een externe server uit te voeren met behulp van een vooraf gedefinieerd formulier en een antwoord te krijgen met hetzelfde formaat. De stijl van de server die de query uitvoert, of het nu een lokale of een externe server is, wordt bij het RPC ontwerp.
Beeldbron itrelease.com/Author Junaid Rehman
De basisfunctie van een RPC API-verzoek is dezelfde als die van een REST API. De RPC API-verzoeken specificeren de interactierichtlijnen en de technieken die interactie mogelijk maken. Later roept de gebruiker deze functies aan met behulp van parameters. De request string van URL's bevat de parameters die worden gebruikt om de operaties aan te roepen.
Om API-verzoeken te creëren, maakt het RPC systeem een client-server structuur. RPC interpreteert de informatie die de gebruiker opvraagt en stuurt die door naar de server. Terwijl de interne communicatie binnen de servers verborgen blijft, antwoordt de server aan de gebruiker. Het RPC model stelt een gebruiker ook in staat om op een bepaalde manier om een dienst te vragen. RPC heeft het voordeel dat het remote procedure calls ondersteunt in zowel gedecentraliseerde als on-premise scenario's.
Wat is REST?
REST - Representational State Transfer - verwijst naar een client-server architectuur waarin gebruikers toegang hebben tot backend informatie via JSON of XML communicatie. Een API wordt als RESTful beschouwd als:
- Het een consistente interface heeft en bepaalde app-bronnen aan de API-clients levert.
- De server en de client afzonderlijk en onafhankelijk werken. Alleen de URI's die verwijzen naar de componenten van de toepassing zijn bekend bij de client.
- Het is stateloos. Dit betekent dat alleen de client toestandsinformatie opslaat. De server slaat geen toestandsgegevens op over de client query.
- Application assets die door de API worden verstrekt moeten in de cache kunnen worden opgeslagen.
- Het heeft een gelaagde architectuur.
Het is een toepassing van hedendaagse architectuurontwerpen die afhankelijk zijn van verschillende beperkingen om gegevensoverdracht in hypermedia netwerken mogelijk te maken. Een RESTful web API heeft URL-gecodeerde argumenten nodig om verbinding te maken met diensten die HTTP-protocollen gebruiken. REST API's zijn uitgebreid omarmd in het hedendaagse webontwerp om stateloze, uitbreidbare en betrouwbare API's te creëren.
Elk onderdeel dat het microservice-systeem combineert, kan aan de gebruiker of klant worden getoond als een bron wanneer de REST API openbaar toegankelijk is gemaakt. Deze bron kan worden opgevraagd met de HTTP-commando's GET, POST, PUT en DELETE .
Hoe werkt REST?
REST gebruikt het HTTP-protocol als het standaard communicatieprotocol bij het werken met diensten die zijn gespecificeerd in API-verzoeken. Een resource is een ding dat vergelijkbaar is met een object in objectgeoriënteerd ontwerp. De RESTful resource heeft acties en attributen, net als een object. In het algemeen besteden REST implementaties minder aandacht aan RESTful acties en concentreren zich meer op de attributen van een resource. RESTful oplossingen zijn oplossingen die alleen attributen gebruiken om een RESTful resource te representeren.
In een RESTful API dient de gebruiker een zoekopdracht in bij een URL - Uniform Resource Locator, die een antwoord veroorzaakt met een payload in JSON, XML, of een ander ondersteund gegevensformaat. Deze payload vertegenwoordigt de bron die de gebruiker wenst. Veel voorkomende clientverzoeken omvatten
- Een HTTP-methode die specificeert wat op de bron moet worden verwerkt
- Het pad van de bron
- De header met gegevens over de aanvraag
- Een cliëntspecifieke payload van het bericht
In het Accept veld van de header specificeert de gebruiker de datatypes die hij kan ontvangen. Een content-type header die het in de respons gebruikte berichtformaat identificeert, wordt door de API-server verzonden samen met de data payload die hij levert aan de gebruiker die de query doet. Een antwoordcode die de gebruiker informeert over de resultaatstatus van de API-aanvraag is ook opgenomen in de response body.
Wat is gRPC?
gRPC - Google Remote Procedure Call - is een subtype van het RPC ontwerp. gRPC is een krachtige globale, open-source RPC architectuur die flexibiliteit en snelheid garandeert voor microservice architectuur. Functie-oproepen worden gebruikt door gRPC om interactie met de klant te garanderen in microservices die met verschillende codetalen zijn gemaakt.
Deze techniek implementeert RPC API-aanvragen met gebruikmaking van de HTTP 2.0 standaard, maar noch de server, noch de API-programmeur is op de hoogte van HTTP. Daardoor wordt de complexiteit verminderd omdat er geen reden is om zich zorgen te maken over hoe RPC principes worden vertaald naar HTTP.
Google Remote Procedure Call wil de gegevensoverdracht tussen microservices versnellen. Om terugkeer en aanroepen op afstand mogelijk te maken, is het gebaseerd op een strategie die een dienst identificeert, de methodologieën vaststelt en de relevante variabelen specificeert.
Bovendien gebruikt het een IDL - Interface description language - om het RPC API-paradigma te specificeren, waardoor het eenvoudiger wordt om functies op afstand te identificeren. De IDL maakt standaard gebruik van protocolbuffers om de service-interface en het formaat van de payload-berichten te definiëren.
Hoe gRPC werkt?
Het HTTP/2-protocol, streaming en protocolbuffers of protobufs worden gebruikt door gRPC API's om berichten te verzenden. Een serialisatiestandaard genaamd protobuf maakt de automatische creatie van gebruikersbibliotheken en de eenvoudige bouw van microservices mogelijk. In protobestanden beschrijven API-ontwerpers de operaties en berichten die tussen servers en clients worden verzonden.
De protoc compiler laadt de bestanden en creëert gebruikers- en serversoftware voor de communicatie met diensten op afstand. Vergeleken met XML of JSON zijn berichten die met protocolbuffers zijn gecodeerd, aanzienlijk kleiner, waardoor de verwerking minder CPU-intensief is.
Bovendien brengt het gebruik van HTTP/2, gRPC API's verschillende verbeteringen voor RPC ontwerp. Het protocol voegt een binaire formaatlaag toe die pakketten opsplitst in kleinere, binair omkaderde berichten, waardoor ze transporteerbaar en klein worden. De uitvoering van vele oproepen binnen een enkel kanaal wordt mogelijk gemaakt door de ondersteuning van HTTP/2 voor meerdere gelijktijdige oproepen met de bidirectionele communicatiearchitectuur.
Het HTTP/2 transportprotocol ondersteunt meerdere gelijktijdige streams, maar gRPC API's breiden deze functionaliteit uit via kanalen. Elk kanaal kan meerdere gelijktijdige streams aan via vele gelijktijdige verbindingen. Kanalen bieden een eenvoudige methode om verbinding te maken met de API-server op een bepaald adres en een bepaalde poort. Een client stub kan ook worden gemaakt via kanalen.
gRPC vs REST: vergelijking
Google creëerde gRPC als een RPC variant om enkele van de beperkingen van bestaande API-architectuurstijlen aan te pakken. Het lost enkele problemen op die samenhangen met REST API's, maar gRPC API's ondervinden bepaalde problemen omdat het een recentere technologie is. Er zijn vele gebruikssituaties waarin REST API's beter geschikt zijn voor uw toepassing. U kunt beslissen welke van deze API's beter bij uw software past zodra u de verschillen tussen beide kent.
HTTP 1.1 vs. HTTP 2
De request-reply benadering die gebruikt wordt door REST API's is voornamelijk gebaseerd op HTTP 1.1. Dit betekent dat het model elke query afzonderlijk moet verwerken als een microservice veel queries krijgt van meerdere clients, wat het hele systeem vertraagt. REST API's kunnen worden ontwikkeld op HTTP 2, maar aangezien de communicatiearchitectuur nog steeds request-response is, kunnen zij de voordelen van HTTP 2, waaronder bidirectionele compatibiliteit en streaming interactie, niet ten volle benutten.
gRPC API's kennen deze uitdaging niet. Het volgt een client-response verbindingsmodel en is gebaseerd op HTTP 2. gRPC kan veel verzoeken van verschillende clients accepteren en die verzoeken tegelijkertijd verwerken via streaming informatie. Deze omstandigheden maken bidirectionele communicatie met streaming interactie mogelijk. Bovendien, gRPC ondersteunt unaire interacties zoals die van HTTP 1.1.
gRPC API's kunnen beheren:
- Unaire interacties
Als een client een enkel verzoek doet, maar slechts één antwoord terugkrijgt. - Server streaming
Er is sprake van serverstreaming als een server een verzoek van een client beantwoordt met een stroom van berichten. De server stuurt ook een statusbericht om de procedure af te ronden nadat alle gegevens zijn verstrekt. - Client-streaming
Hiervan is sprake wanneer de client een reeks berichten levert, en de server antwoordt met één enkel bericht. - Bidirectionele streaming
Dit maakt gegevensoverdracht in beide richtingen mogelijk, omdat de kanalen van server en client onafhankelijk van elkaar zijn.
Browserondersteuning
Aangezien de meeste web API interactie online plaatsvindt, is browser ondersteuning een belangrijke overweging in het gRPC vs. REST debat. Browserondersteuning is waarschijnlijk een van de belangrijkste voordelen van REST API's ten opzichte van gRPC. Alle browsers bieden volledige REST API-mogelijkheden en browserondersteuning. De functionaliteit voor gRPC in browsers is echter nog relatief beperkt. Helaas zijn voor overgangen tussen HTTP 1.1 en HTTP 2 zowel gRPC-web als een proxy-laag nodig. Als gevolg daarvan, gRPC API's worden uiteindelijk vooral gebruikt voor interne of particuliere systemen, bijvoorbeeld in API-applicaties die worden gebruikt voor de backend-informatie en -functionaliteit van specifieke organisaties.
Multiplexed streams worden gebruikt met het HTTP/2-protocol. Daardoor kunnen talrijke klanten parallel queries versturen zonder dat voor elke query een nieuwe TCP-sessie moet worden geopend. Bovendien kan de server de bestaande verbinding gebruiken om berichten af te leveren aan klanten.
Het representational state transfer model heeft wijdverbreide browserondersteuning omdat het HTTP 1.1 integreert. HTTP 1.1, dat REST mogelijk maakt, gebruikt een TCP-handshaking methode voor elke query. REST API's hebben daardoor vaak problemen met latency, omdat de handshake tijd kost.
De gegevensstructuur van de payload
Als we kijken naar de payload datastructuur terwijl we kijken naar gRPC vs REST, gRPC API's serialiseren payload data door middel van Protocol Buffers. Deze methode is lichter omdat ze de berichten kleiner maakt en een sterk gecomprimeerde structuur mogelijk maakt. Protocolbuffers zijn in binair formaat; daarom serialiseert en deserialiseert het voor gegevensuitwisseling de informatie. Protobuf kan zwaar geschreven berichten automatisch vertalen naar de client- en serverprogrammeertalen.
RESTMeestal worden echter JSON of XML-vormen gebruikt om informatie te leveren en te ontvangen. JSON is het meest gebruikte formaat vanwege zijn aanpassingsvermogen en zijn vermogen om dynamische gegevens mee te delen zonder zich te houden aan een precieze structuur, hoewel die niet vereist is. De menselijke leesbaarheid van JSON, waar Protobuf nog niet aan kan tippen, is een ander belangrijk voordeel.
JSON is echter niet zo snel of licht als het gaat om gegevensoverdracht. Dit komt door de eis dat JSON moet worden geserialiseerd en vertaald naar de programmeertalen die zowel op de server als op de client worden gebruikt bij gebruik van REST. Dit is een extra stap in het proces van gegevensoverdracht, die de efficiëntie kan schaden en de kans op fouten kan vergroten.
Het genereren van code
Ingenieurs moeten hulpmiddelen van derden, zoals Postman, gebruiken voor het genereren van code voor API-queries, omdat, en in tegenstelling tot gRPCde REST API geen ingebouwde faciliteiten voor het genereren van code heeft. In tegenstelling hiertoe, gRPC biedt native functies voor codegeneratie dankzij zijn protoc compiler, die vele programmeertalen ondersteunt. Codegeneratie is vooral voordelig voor microservices die talrijke diensten combineren die op verschillende platformen en talen zijn gemaakt. In het algemeen maakt de ingebouwde codegeneratie het bouwen van de softwareontwikkelingskit - SDK - gemakkelijker.
REST API, aan de andere kant, biedt geen native functies voor het genereren van code. U moet een programma van derden gebruiken om code te genereren voor API-aanroepen in verschillende talen. Hoewel het geen gedoe is, is het belangrijk op te merken dat gRPC niet afhankelijk is van andere diensten voor het genereren van code.
Wanneer REST API's gebruiken?
Bij het vergelijken van gRPC vs REST, zijn de meest gebruikte en meest geliefde API's voor de integratie van infrastructuren gebouwd op microservices REST API's. REST API's zullen waarschijnlijk nog heel lang de standaardoptie blijven voor app-verbinding, ongeacht of u een intern netwerk creëert of een open platform dat zijn activa openstelt voor de rest van de wereld. REST API's zijn ook perfect voor systemen die snelle iteratie en HTTP-protocolnormen vereisen.
REST API's kunnen uw eerste keuze zijn voor de ontwikkeling van webservices, microservices en app-interfaces, omdat technologieën van derden ze universeel ondersteunen. In tegenstelling tot gRPC, heeft het brede browserondersteuning en is het niet beperkt tot private systemen. Dit kan REST API's zeer nuttig maken in vele contexten.
Het is ook gemakkelijker om REST te leren, omdat er veel API-documentatie beschikbaar is op het internet. Deze eenvoudigere leercurve is erg belangrijk als u weinig tijd hebt. U kunt veel tijd besparen bij het onderzoeken en leren en onmiddellijk beginnen met implementeren. RESTful API's zijn ook gemakkelijker te integreren in toepassingen. Ze bieden ook een betere schaalbaarheid. Als u uw applicatie binnenkort wilt uitbreiden, is het misschien beter om REST API's te gebruiken. Het gebrek aan toestand en vertrouwelijkheid kan problemen veroorzaken met representatieve toestandsoverdracht in bepaalde toepassingen. Als uw applicatie een betalingsoptie heeft, gRPC kan het een betere optie zijn.
Wanneer te gebruiken gRPC API's
In zowel gRPC vs REST bieden de meeste tools van derden nog steeds geen ingebouwde functionaliteit voor gRPC compliance. Bijgevolg, gRPC API's meestal gebruikt om interne systemen of structuren te creëren die niet toegankelijk zijn voor externe gebruikers. Met die kwalificatie in gedachten zouden de volgende situaties gebruik kunnen maken van gRPC API's:
- Microservices-verbindingen
gRPC API's zijn vooral nuttig voor het koppelen van architecturen die bestaan uit lichte microservices waarbij de effectiviteit van de berichtlevering cruciaal is vanwege de lage latency en snelle bandbreedte communicatie.
- Meertalige systemen
gRPC blinkt uit in het afhandelen van communicatie in een polyglot context dankzij zijn native code generatie mogelijkheid voor een breed scala aan programmeertalen.
- Real-time streaming
Als real-time communicatie noodzakelijk is, kan uw systeem gegevens in real-time verzenden en ontvangen zonder te hoeven wachten op eenmalige client-respons interactie dankzij de mogelijkheid van gRPC om bidirectionele streaming aan te kunnen.
- Netwerken met laag vermogen en lage bandbreedte
Dergelijke netwerken kunnen profiteren van gRPC's gebruik van geserialiseerde Protobuf sessies omdat deze lichtgewicht communicatie, verbeterde efficiëntie en snelheid bieden. Een netwerk dat bijvoorbeeld zou profiteren van de gRPC API is het internet der dingen.
Hoe helpt AppMaster?
Programmeren is de laatste decennia sterk veranderd, met nieuwe technologieën en frameworks die de taken van ontwikkelaars gemakkelijker maken. No-code generatie tilt dit naar een hoger niveau. Mensen hoeven geen steile leercurve te doorlopen en kunnen sneller toepassingen ontwikkelen met no-code platforms als AppMaster.
AppMaster helpt u broncode vanaf nul te creëren volgens de specifieke behoeften van uw toepassing. De gegenereerde code is van u, en u kunt deze aanpassen aan uw behoeften. U kunt de verschillende modules die uw toepassing nodig heeft aanmaken met AppMaster. Dit is veel minder duur en tijdrovend dan een heel ontwikkelingsteam in te schakelen.
Ontwikkelaars kunnen queries sturen tussen de backend microservices architectuur met behulp van het gRPC protocol met behulp van AppMaster's no-code genererende platform. We zullen API toevoegen aan zowel gRPC web services ontwikkeling als aan gRPC mobiele apps het volgende jaar om de gRPC ondersteuning te vergroten.
Conclusie
Representational state transfer was in het verleden de aangewezen benadering voor API-ontwikkeling. Maar tussen gRPC vs REST, gRPC API's worden langzaam populairder. Ondanks de verschillende kenmerken die het onderscheidend maken, maken sommige problemen, zoals het gebrek aan browserondersteuning en API-documentatie, het moeilijk om het overal toe te passen. Met de technologische vooruitgang en de groei van de gemeenschap kunnen we echter hopen dat gRPC de huidige uitdagingen zal overwinnen.
Tot slot, de keuze tussen REST of gRPCof zelfs een van de andere API-methoden zoals GraphQL of SOAP, hangt af van de specifieke behoeften van uw project. Sommige toepassingen hebben misschien de voordelen nodig die gRPC biedt, terwijl andere de basisfunctionaliteit nodig hebben die REST biedt. U moet de functies en use cases van uw toepassing evalueren om te kunnen kiezen tussen deze twee bekwame technologieën.
