Forse vi sarà capitato di sentir pronunciare parole come REST quando si parla di sviluppo software. REST è un'architettura API molto usata e gli sviluppatori la utilizzano ampiamente per progettare le API del software. Le interfacce di programmazione delle applicazioni sono fondamentali per qualsiasi applicazione software e REST è una delle tante architetture utilizzate per le API.
Al giorno d'oggi, gRPC è un'architettura che sta guadagnando popolarità e che sostiene di risolvere alcuni problemi tradizionalmente associati alle APIREST . Ma in cosa differiscono? E quale utilizzare per la propria applicazione? Per conoscere la risposta a queste domande, dobbiamo capire meglio quali sono le caratteristiche di gRPC rispetto a REST e in quali scenari si comportano meglio. Ma prima di entrare nel merito, vediamo cosa sono le API e cosa apportano ai microservizi.
Che cos'è un'API?
Le applicazioni software possono interagire e comunicare tra loro attraverso l'uso di interfacce di programmazione delle applicazioni (API), che operano come mediatori tecnici. Un'API ha il compito di inviare una richiesta dell'utente al sistema, che poi riceve una risposta dal sistema.
Immaginate di dover ordinare un telefono online. Si va su un sito collegato al web, che invia le informazioni sulla richiesta a un server. Il server riceve le informazioni, le analizza e, dopo aver compiuto i passi necessari, ci risponde con i dettagli visualizzati sullo schermo. Tutto questo è possibile grazie alle API.
Le API descrivono come eseguire le richieste dei client, quali strutture di dati utilizzare e gli standard che i client devono rispettare. Descrive anche i tipi di query che un programma può inviare a un altro. Entrambi gli stili di architettura gRPC REST stili di architettura sono ampiamente utilizzati per progettare le API.
API e microservizi
Le applicazioni possono avere un'architettura monolitica o un'architettura a microservizi. In un'applicazione monolitica, tutte le funzioni e i moduli del software sono contenuti in un'unica unità o base di codice. Un'applicazione a microservizi, invece, è costituita da numerose unità più piccole che interagiscono tra loro attraverso interfacce come il protocollo HTTP.
Il problema principale dello stile monolitico è che diventa più difficile modificare, aggiornare ed espandere il sistema man mano che gli ingegneri aggiungono nuove funzioni e servizi alla base preesistente. Una modifica a un aspetto dell'applicazione può avere un effetto negativo su altre sezioni. Il codice di un monolite diventa gradualmente così intrecciato e difficile da comprendere dopo essere stato scalato, aggiornato e modificato numerose volte, da richiedere una riprogettazione completa del sistema.
Questo problema viene risolto con i microservizi. Questo design architettonico divide un monolite nei suoi componenti costitutivi, ognuno dei quali viene eseguito come applicazione separata. Ciascuna di queste applicazioni è chiamata microservizio. Poi, questi microservizi distinti si collegano tramite API. Questa collezione di microservizi collegati da API si riunisce per costruire un'architettura più grande. Le API consentono la connessione e la comunicazione tra ogni componente incorporato in un'architettura di microservizi. Alcuni approcci popolari alla creazione di API sono GraphQL, RPC, e REST.
Che cos'è RPC?
Una RPC - Remote Procedure Call - è un'architettura web che consente di eseguire un servizio su un server remoto utilizzando un modulo predefinito e di ottenere una risposta con lo stesso formato. Lo stile del server che esegue l'interrogazione, sia esso locale o remoto, non è preso in considerazione dal progetto. RPC progettazione.
Fonte immagine itrelease.com/Autore Junaid Rehman
La funzione di base di una RPC richiesta API è la stessa di un'API REST. Le RPC Le richieste API specificano le linee guida dell'interazione e le tecniche che rendono possibile l'interazione. In seguito, l'utente chiama queste funzioni utilizzando dei parametri. La stringa di richiesta degli URL contiene i parametri utilizzati per chiamare le operazioni.
Per creare le richieste API, il sistema RPC sistema utilizza una struttura client-server. RPC interpreta le informazioni richieste dall'utente e le trasmette al server. Mentre le comunicazioni interne ai server sono nascoste, il server risponde all'utente. Il modello RPC modello consente inoltre all'utente di richiedere un servizio in un modo particolare. RPC ha il vantaggio di supportare le chiamate di procedura remota in scenari sia decentralizzati che on-premises.
Che cos'è REST?
REST - Representational State Transfer - si riferisce a un'architettura client-server in cui gli utenti hanno accesso alle informazioni di backend tramite JSON o comunicazione XML. Un'API è considerata RESTful se:
- Ha un'interfaccia coerente e fornisce particolari risorse dell'applicazione ai client dell'API.
- Il server e il client lavorano separatamente e in modo indipendente. Il client conosce solo gli URI che puntano ai componenti dell'applicazione.
- È stateless. Ciò significa che solo il client salva le informazioni sullo stato. Il server non salverà alcun dato di stato sulla query del client.
- Le risorse dell'applicazione fornite dall'API devono essere memorizzabili nella cache.
- Ha un'architettura a strati.
È un'applicazione dei progetti architettonici contemporanei che dipendono da diverse restrizioni per consentire la trasmissione dei dati nelle reti ipermediali. Un'API web RESTful necessita di argomenti codificati in URL per connettersi ai servizi che utilizzano i protocolli HTTP. REST Le API sono state ampiamente adottate nella progettazione web contemporanea per creare API stateless, estensibili e affidabili.
Ogni componente che combina il sistema di microservizi può essere mostrato all'utente o al cliente come una risorsa quando l'API REST è resa pubblicamente accessibile. Questa risorsa può essere interrogata utilizzando i comandi HTTP GET, POST, PUT e DELETE .
Come funziona REST?
REST utilizza il protocollo HTTP come protocollo di comunicazione predefinito quando lavora con i servizi specificati nelle richieste API. Una risorsa è una cosa paragonabile a un oggetto nella progettazione orientata agli oggetti. La risorsa RESTful ha azioni e attributi, proprio come un oggetto. In generale, le implementazioni di REST danno meno importanza alle azioni RESTful e si concentrano maggiormente sugli attributi di una risorsa. Le soluzioni RESTful sono quelle che utilizzano solo gli attributi per rappresentare una risorsa RESTful.
In un'API RESTful, l'utente invia una query a un URL (Uniform Resource Locator), che provoca una risposta con un payload in JSON, XML o qualsiasi altro formato di dati supportato. Questo payload rappresenta la risorsa desiderata dall'utente. Le richieste comuni dei client includono
- Un metodo HTTP che specifica ciò che deve essere elaborato sulla risorsa
- Il percorso della risorsa
- L'intestazione che contiene i dati della richiesta
- Un payload di messaggio specifico del client
Nel campo Accept dell'intestazione, l'utente specifica i tipi di dati che è in grado di ricevere. Un'intestazione content-type che identifica il formato di consegna del messaggio utilizzato nel corpo della risposta viene inviata dal server API insieme al carico di dati che consegna all'utente che effettua la query. Nel corpo della risposta è incluso anche un codice di risposta che informa l'utente sullo stato dei risultati della chiamata API.
Che cos'è gRPC?
gRPC - Google Remote Procedure Call - è un sottotipo del progetto RPC. gRPC è un'architettura RPC globale e open-source ad alte prestazioni che garantisce flessibilità e velocità per l'architettura di microservizi. Le chiamate di funzione sono utilizzate da gRPC per garantire l'interazione con il cliente nei microservizi creati con diversi linguaggi di codifica.
Questa tecnica implementa le richieste API RPC utilizzando lo standard HTTP 2.0, ma né il server né il programmatore dell'API sono a conoscenza di HTTP. Di conseguenza, la complicazione diminuisce perché non c'è motivo di preoccuparsi di come i principi di RPC siano tradotti in HTTP.
Google Remote Procedure Call cerca di accelerare il trasferimento dei dati tra i microservizi. Per consentire il ritorno e la chiamata remoti, si basa su una strategia che identifica un servizio, stabilisce le metodologie e specifica le variabili pertinenti.
Inoltre, utilizza un IDL - linguaggio di descrizione delle interfacce - per specificare il paradigma dell'API RPC, rendendo più semplice l'identificazione delle funzioni remote. IDL impiega per default i buffer di protocollo per definire l'interfaccia del servizio e il formato dei messaggi di payload.
Come funziona gRPC funziona?
Il protocollo HTTP/2, lo streaming e i buffer di protocollo o protobufs vengono utilizzati dalle gRPC API per trasmettere messaggi. Uno standard di serializzazione chiamato protobuf consente la creazione automatica di librerie utente e la costruzione semplice di microservizi. Nei file proto, i progettisti di API descrivono le operazioni e i messaggi che vengono inviati tra server e client.
Il compilatore protoc carica i file e crea software utente e server per comunicare con i servizi remoti. Rispetto ai formati XML o JSON, i messaggi codificati con i protocol buffer sono notevolmente più piccoli, rendendo l'elaborazione meno CPU impegnativa.
Inoltre, l'uso di HTTP/2, gRPC le API apportano diversi miglioramenti alla progettazione di RPC. Il protocollo aggiunge un livello di formato binario che divide i pacchetti in messaggi più piccoli, con cornice binaria, rendendoli trasportabili e di dimensioni ridotte. L'esecuzione di molte chiamate all'interno di un singolo canale è resa possibile dal supporto di HTTP/2 per più interrogazioni simultanee con l'architettura di comunicazione bidirezionale.
Il protocollo di trasporto HTTP/2 supporta più flussi simultanei, ma le gRPC Le API espandono questa funzionalità tramite i canali. Ogni canale può ospitare diversi flussi in esecuzione simultanea tramite molte connessioni simultanee. I canali offrono un metodo semplice per connettersi al server API a un determinato indirizzo e porta. Anche uno stub client può essere creato tramite i canali.
gRPC vs REST: confronto
Google ha creato gRPC come variante di RPC per far fronte ad alcune limitazioni degli stili di architettura API esistenti. Risolve alcuni problemi associati alle API REST, ma le API devono affrontare alcuni problemi. gRPC Le API devono affrontare alcuni problemi dovuti al fatto che si tratta di una tecnologia più recente. Ci sono molti casi d'uso in cui le API di REST possono essere più adatte alla vostra applicazione. È possibile decidere quale di queste API potrebbe funzionare meglio con il proprio software una volta conosciute le differenze tra le due.
HTTP 1.1 vs HTTP 2
L'approccio request-reply utilizzato dalle API di REST si basa principalmente su HTTP 1.1. Ciò significa che il modello deve elaborare ogni richiesta singolarmente se un microservizio riceve molte richieste da più client, con conseguente rallentamento dell'intero sistema. REST Le API possono essere sviluppate su HTTP 2, ma poiché l'architettura di comunicazione è ancora richiesta-risposta, non sono in grado di utilizzare pienamente i vantaggi di HTTP 2, tra cui la compatibilità bidirezionale e l'interazione in streaming.
gRPC Le API non incontrano questa sfida. Aderisce a un modello di connessione cliente-risposta e si basa su HTTP 2. gRPC può accettare molte richieste da vari client ed elaborarle contemporaneamente tramite informazioni in streaming. Queste circostanze consentono una comunicazione bidirezionale con interazione in streaming. Inoltre, gRPC supporta le interazioni unarie come quelle create da HTTP 1.1.
gRPC Le API possono gestire:
- Interazioni unarie
Se un client effettua una singola richiesta, ma riceve in cambio una sola risposta. - Streaming del server
Si parla di server streaming quando un server risponde a una richiesta del client con un flusso di messaggi. Il server invia anche un messaggio di stato per concludere la procedura dopo aver fornito tutti i dati. - Streaming del client
Si verifica quando il client invia una sequenza di messaggi e il server risponde con un singolo messaggio. - Streaming bidirezionale
Consente la trasmissione dei dati in entrambe le direzioni, perché i canali del server e del client sono indipendenti l'uno dall'altro.
Supporto del browser
Poiché la maggior parte delle interazioni con le API web avviene online, il supporto del browser è una considerazione fondamentale nel dibattito tra gRPC vs. REST. Il supporto del browser è probabilmente uno dei vantaggi principali delle API di REST rispetto alle API di . gRPC. Tutti i browser offrono la piena funzionalità dell'API REST e il supporto del browser. La funzionalità di gRPC nei browser, tuttavia, è ancora relativamente limitata. Purtroppo, le transizioni tra HTTP 1.1 e HTTP 2 richiedono gRPC-web e un livello proxy. Di conseguenza, gRPC Le API tendono a essere utilizzate principalmente per sistemi interni o privati, ad esempio nelle applicazioni API utilizzate per le informazioni e le funzionalità di backend di specifiche organizzazioni.
Con il protocollo HTTP/2 vengono utilizzati flussi multipli. Di conseguenza, numerosi clienti possono inviare query in parallelo senza dover aprire una nuova sessione TCP per ciascuno di essi. Inoltre, il server può utilizzare il collegamento esistente per consegnare i messaggi ai clienti.
Il modello di trasferimento di stato rappresentazionale gode di un ampio supporto da parte dei browser perché integra HTTP 1.1. HTTP 1.1, che REST abilita, utilizza un metodo di handshaking TCP per ogni interrogazione. REST Di conseguenza, le API hanno spesso problemi di latenza, poiché l'handshake richiede tempo.
La struttura dei dati del payload
Se si osserva la struttura dei dati del payload in un'analisi di gRPC vs REST, gRPC Le API serializzano i dati del payload utilizzando i buffer di protocollo. Questo metodo è più leggero perché rende i messaggi più piccoli e consente una struttura altamente compressa. I buffer di protocollo sono in formato binario; pertanto, per lo scambio di dati, serializzano e deserializzano le informazioni. Protobuf è in grado di tradurre automaticamente messaggi molto scritti nei linguaggi di programmazione del client e del server.
REST JSON JSON è il formato più utilizzato per la sua adattabilità e la capacità di comunicare dati dinamici senza aderire a una struttura precisa, sebbene non ne richieda alcuna. La qualità della leggibilità umana di JSON, che Protobuf non è ancora in grado di eguagliare, è un altro importante vantaggio.
JSON Tuttavia, JSON non è altrettanto veloce e leggero quando si tratta di trasferire dati. Ciò è dovuto al fatto che JSON deve essere serializzato e tradotto nei linguaggi di programmazione utilizzati sia sul server che sul client quando si utilizza REST. Si tratta di un passaggio aggiuntivo nel processo di trasmissione dei dati, che potrebbe compromettere l'efficienza e aumentare la probabilità di errori.
Generazione del codice
Gli ingegneri devono impiegare strumenti di terze parti, come Postman, per la generazione di codice per le interrogazioni API, poiché, a differenza di quanto avviene per le API, l'API non dispone di strumenti integrati. gRPC, l'API REST non dispone di strutture integrate per la generazione di codice. Al contrario, gRPC offre funzioni native di generazione del codice grazie al suo compilatore protoc, che supporta molti linguaggi di programmazione. La generazione di codice è particolarmente vantaggiosa per i microservizi che combinano numerosi servizi creati su più piattaforme e linguaggi. In generale, la generazione di codice integrata facilita la costruzione del kit di sviluppo software (SDK).
REST API, invece, non fornisce funzioni di generazione di codice nativo. È necessario utilizzare un programma di terze parti per generare codice per le chiamate API in diverse lingue. Anche se non è una seccatura, è importante notare che gRPC non si affida ad altri servizi per la generazione del codice.
Quando utilizzare le API di REST
Nel confronto gRPC vs REST, le API più utilizzate e apprezzate per l'integrazione di infrastrutture costruite su microservizi sono le API di REST. REST È probabile che le API continuino a essere l'opzione predefinita per la connessione delle app per molto tempo, indipendentemente dal fatto che si stia creando una rete interna o una piattaforma aperta che apre le proprie risorse al resto del mondo. REST Le API sono perfette anche per i sistemi che richiedono una rapida iterazione e gli standard del protocollo HTTP.
REST Le API possono essere la prima scelta per lo sviluppo di servizi web, microservizi e interfacce per app, perché le tecnologie di terze parti le supportano universalmente. A differenza di gRPCha un ampio supporto per i browser e non è limitato ai sistemi privati. Questo può rendere le API di REST molto utili in molti contesti.
È anche più facile imparare REST, perché ha un'ampia documentazione sulle API disponibile su Internet. Questa curva di apprendimento più semplice è molto importante se si ha poco tempo a disposizione. Si può risparmiare molto tempo nella ricerca e nell'apprendimento e iniziare subito l'implementazione. Le API RESTful sono anche più facili da integrare nelle applicazioni. Offrono anche una migliore scalabilità. Se si vuole espandere la propria applicazione in tempi brevi, è meglio utilizzare le API REST. La mancanza di stato e di riservatezza può causare problemi con il trasferimento di stato rappresentazionale in alcune applicazioni. Se l'applicazione prevede un'opzione di pagamento, gRPC può essere un'opzione migliore.
Quando utilizzare gRPC API
In entrambi i casi gRPC REST, la maggior parte degli strumenti di terze parti non fornisce ancora funzionalità integrate per la conformità. gRPC conformità. Di conseguenza, gRPC Le API sono per lo più utilizzate per creare sistemi o strutture interne inaccessibili agli utenti esterni. Tenendo presente questa qualifica, le seguenti situazioni potrebbero fare uso di gRPC API:
- Connessioni a microservizi
gRPC Le API sono particolarmente utili per collegare architetture composte da microservizi leggeri, in cui l'efficacia della consegna dei messaggi è cruciale grazie alla bassa latenza e alla rapida larghezza di banda della comunicazione.
- Sistemi multilingue
gRPC gRPC eccelle nella gestione delle comunicazioni in un contesto poliglotta, grazie alla sua capacità di generare codice nativo per un'ampia gamma di linguaggi di programmazione.
- Streaming in tempo reale
Se è necessaria una comunicazione in tempo reale, il sistema può trasmettere e ricevere dati in tempo reale senza dover attendere l'interazione client-risposta unaria, grazie alla capacità di gRPC di gestire lo streaming bidirezionale.
- Reti a basso consumo e a bassa larghezza di banda
Tali reti possono trarre vantaggio dall'uso di sessioni Protobuf serializzate da parte di gRPC, in quanto forniscono comunicazioni leggere, maggiore efficienza e rapidità. Ad esempio, una rete che potrebbe trarre vantaggio dall'API è l'Internet degli oggetti. gRPC API è l'Internet degli oggetti.
Come può aiutare AppMaster?
La programmazione è cambiata molto negli ultimi decenni, con nuove tecnologie e framework che hanno semplificato i compiti degli sviluppatori. La generazione No-code porta questo aspetto a un livello superiore. Le persone non devono affrontare curve di apprendimento ripide e possono sviluppare applicazioni più rapidamente con piattaforme come . no-code piattaforme come AppMaster.
AppMaster vi aiuta a creare codice sorgente da zero in base alle esigenze specifiche della vostra applicazione. Il codice generato sarà di vostra proprietà e potrete modificarlo secondo le vostre esigenze. Con AppMaster potete creare i vari moduli di cui la vostra applicazione ha bisogno. È molto meno costoso e dispendioso in termini di tempo rispetto alla creazione di un intero team di sviluppo.
Gli sviluppatori possono inviare query tra l'architettura dei microservizi di backend utilizzando il protocollo gRPC utilizzando la piattaforma di generazione no-code di AppMaster. Aggiungeremo API sia per lo gRPC sviluppo di servizi web e alle gRPC applicazioni mobili l'anno successivo per aumentare gRPC supporto.
Conclusione
In passato, il trasferimento di stato rappresentativo era l'approccio preferito per lo sviluppo di API. Ma tra gRPC vs REST, gRPC le API stanno lentamente diventando più popolari. Nonostante le varie caratteristiche che le contraddistinguono, alcuni problemi, come la mancanza di supporto per i browser e di documentazione sulle API, rendono difficile il loro impiego ovunque. Tuttavia, con i progressi tecnologici e la crescita della comunità, possiamo sperare che gRPC supererà le sfide attuali.
Infine, la scelta tra REST o gRPCo una delle altre metodologie API, come GraphQL o SOAP, dipende dalle esigenze specifiche del progetto. Alcune applicazioni potrebbero aver bisogno dei vantaggi che gRPC mentre altre potrebbero richiedere le funzionalità di base offerte da REST. È necessario valutare le funzioni e i casi d'uso della propria applicazione per scegliere tra queste due tecnologie.
