Qual è la differenza tra RPC e REST?
Remote Procedure Call (RPC) e REST sono due stili architettonici nella progettazione delle API. Le API sono meccanismi che consentono a due componenti software di comunicare tra loro usando una serie di definizioni e protocolli. Per eseguire le funzioni, gli sviluppatori di software non scrivono tutto da zero ma utilizzano componenti sviluppati in precedenza o di terze parti. Le API RPC consentono agli sviluppatori di richiamare funzioni remote su server esterni come se fossero locali nel loro software. Ad esempio, puoi aggiungere funzionalità di chat alla tua applicazione chiamando in remoto le funzioni di messaggistica su un'altra applicazione di chat. Al contrario, le REST API consentono di eseguire operazioni specifiche sui dati su un server remoto. Ad esempio, l'applicazione potrebbe inserire o modificare i dati dei dipendenti su un server remoto utilizzando le REST API.
Quali sono le similitudini tra RPC e REST?
Remote Procedure Call (RPC) e REST sono due modi diversi per progettare le API. Le API sono fondamentali nel moderno Web design e in altri sistemi distribuiti. Consentono a due applicazioni o servizi distribuiti separati di comunicare senza conoscere gli aspetti interni del funzionamento dell'altro. Queste due applicazioni o servizi potrebbero avere poco a che fare l'una con l'altra tranne che per un piccolo scambio di dati.
Le API sono anche un meccanismo comune per il back-end di un programma (il componente logico) per comunicare con il front-end di un programma (il componente di visualizzazione). Quando si progettano pagine Web e applicazioni Web con API anziché con un'integrazione strettamente accoppiata, si garantisce che possano essere scalabili e modificate con meno riscritture del codice.
Successivamente, discuteremo di altre somiglianze tra le API RPC e le REST API.
Astrazione
Sebbene le comunicazioni di rete siano l'obiettivo principale delle API, le stesse comunicazioni di livello inferiore vengono astratte dagli sviluppatori di API. Ciò consente agli sviluppatori di concentrarsi sulla funzione piuttosto che sull'implementazione tecnica.
Comunicazione
Sia REST che RPC utilizzano HTTP come protocollo sottostante. I formati di messaggi più diffusi in RPC e REST sono JSON e XML. JSON è preferito per la sua leggibilità e flessibilità.
Compatibilità interlinguistica
Gli sviluppatori possono implementare un'API RESTful o RPC in qualsiasi linguaggio scelgano. A condizione che l'elemento di comunicazione di rete dell'API sia conforme allo standard di interfaccia RESTful o RPC, puoi scrivere il resto del codice in qualsiasi linguaggio di programmazione.
Principi di architettura di RPC e REST
In Remote Procedure Call (RPC), il client effettua una chiamata di funzione remota (nota anche come metodo o procedura) su un server. In genere, durante la chiamata vengono passati al server uno o più valori di dati.
Al contrario, il client REST richiede al server di eseguire un'azione su una specifica risorsa del server. Le azioni sono limitate alla sola creazione, lettura, aggiornamento ed eliminazione (CRUD) e vengono trasmesse come verbi HTTP o metodi HTTP.
RPC si concentra su funzioni o azioni, mentre REST si concentra su risorse o oggetti.
Principi di RPC
Successivamente, discuteremo alcuni principi che i sistemi RPC seguono in genere. Tuttavia, questi principi non sono standardizzati come REST.
Invocazione remota
Una chiamata RPC viene effettuata da un client a una funzione sul server remoto come se fosse chiamata localmente dal client.
Invio di parametri
Il client in genere invia parametri a una funzione del server in modo molto simile a una funzione locale.
Stub
Gli stub delle funzioni esistono sia sul client che sul server. Sul lato client, effettua la chiamata alla funzione. Sul server, richiama la funzione effettiva.
Principi di REST
I principi di REST sono standardizzati. Per essere classificata come RESTful, una REST API deve seguire questi principi.
Client-server
L'architettura client-server di REST separa client e server. Li tratta come sistemi indipendenti.
Stateless
Il server non registra lo stato del client tra le richieste del client.
Memorizzabile nella cache
Il client o i sistemi intermediari possono memorizzare nella cache le risposte del server in base al fatto che un client specifichi che la risposta può essere memorizzata nella cache.
Sistema a livelli
Possono esistere intermediari tra il client e il server. Sia il client che il server non ne sono a conoscenza e funzionano come se fossero connessi direttamente.
Interfaccia uniforme
Il client e il server comunicano tramite un set standardizzato di istruzioni e formati di messaggistica con la REST API. Le risorse sono identificate dal relativo URL e questo URL è noto come endpoint REST API.
Come funzionano: RPC e REST
In Remote Procedure Call (RPC), il client utilizza HTTP POST per chiamare una funzione specifica per nome. Affinché RPC funzioni, gli sviluppatori lato client devono conoscere in anticipo il nome e i parametri della funzione.
Per eseguire le opzioni in REST, client e server utilizzano verbi HTTP come GET, POST, PATCH, PUT, DELETE e OPTIONS. Gli sviluppatori devono conoscere solo gli URL delle risorse del server e non devono preoccuparsi dei nomi delle singole funzioni.
La tabella seguente mostra il tipo di codice utilizzato dal client per eseguire azioni simili in RPC e REST.
| Operazione |
RPC |
REST |
Commento |
| Aggiunta di un nuovo prodotto a un elenco di prodotti |
POST /addProduct HTTP/1.1 HOST: api.example.com Content-Type: application/json {"name": "T-Shirt", "price": "22.00", "category": "Clothes"} |
POST /products HTTP/1.1 HOST: api.example.com Content-Type: application/json {"name": "T-Shirt", "price": "22.00", "category": "Clothes"} |
RPC utilizza POST sulla funzione e REST utilizza POST sull'URL. |
| Recupero dei dettagli di un prodotto |
POST /getProduct HTTP/1.1 HOST: api.example.com Content-Type: application/json {"productID": "123”} |
GET /products/123 HTTP/1.1 HOST: api.example.com |
RPC utilizza POST sulla funzione e passa il parametro come oggetto JSON. REST utilizza GET su URL e passa il parametro nell'URL. |
| Aggiornamento del prezzo di un prodotto |
POST /updateProductPrice HTTP/1.1 HOST: api.example.com Content-Type: application/json {"productId": "123", "newPrice": "20.00"} |
PUT /products/123 HTTP/1.1 HOST: api.example.com Content-Type: application/json {"price": "20.00"} |
RPC utilizza POST sulla funzione e passa il parametro come oggetto JSON. REST utilizza PUT sull'URL e invia il parametro nell'URL e come oggetto JSON. |
| Eliminazione di un prodotto |
POST /deleteProduct HTTP/1.1 HOST: api.example.com Content-Type: application/json {"productId": "123""} |
DELETE /products/123 HTTP/1.1 HOST: api.example.com |
RPC utilizza POST sulla funzione e passa il parametro come oggetto JSON. REST utilizza DELETE sull'URL e invia il parametro nell'URL. |
Principali differenze tra RPC e REST
Di seguito sono riportate altre differenze.
Facilità di sviluppo
RPC è stato sviluppato tra la fine degli anni '70 e l'inizio degli anni '80, mentre REST è stato un termine coniato per la prima volta dall'informatico Roy Fielding nel 2000.
Formato operativo
Una REST API dispone di un set standardizzato di operazioni del server grazie ai metodi HTTP, mentre le API RPC no. Alcune implementazioni RPC forniscono un framework per operazioni standardizzate.
Formato di trasferimento dei dati
REST può passare qualsiasi formato di dati e più formati, come JSON e XML, all'interno della stessa API.
Tuttavia, con le API RPC, il formato dei dati viene selezionato dal server e corretto durante l'implementazione. È possibile avere implementazioni JSON RPC o XML RPC specifiche e il client non ha alcuna flessibilità.
Stato
Nel contesto delle API, il termine stateless si riferisce a un principio di progettazione in cui il server non memorizza alcuna informazione sulle precedenti interazioni del client. Ogni richiesta API viene trattata in modo indipendente e il server non si basa su nessuno stato del client memorizzato per elaborare la richiesta.
I sistemi REST devono essere sempre stateless, ma i sistemi RPC possono essere stateful o stateless, a seconda del design.
Quando usare RPC e REST
La chiamata di procedura remota (RPC) viene in genere utilizzata per chiamare funzioni remote su un server che richiedono il risultato di un'azione. È possibile utilizzarlo quando si richiedono calcoli complessi o si desidera attivare una procedura remota sul server, con il processo nascosto al client.
Ecco alcuni casi in cui RPC è una buona opzione:
- Una foto con la fotocamera di un dispositivo remoto
- Utilizzo di un algoritmo di machine learning sul server per identificare le frodi
- Trasferimento di denaro da un conto all'altro su un sistema bancario remoto
- Riavvio di un server da remoto
Una REST API viene in genere utilizzata per eseguire operazioni di creazione, lettura, aggiornamento ed eliminazione (CRUD) su un oggetto dati su un server. Ciò rende le REST API ideali per i casi in cui i dati e le strutture di dati del server devono essere esposti in modo uniforme.
Ecco alcuni casi in cui una REST API è una buona opzione:
- Aggiunta di un prodotto a un database
- Recupero del contenuto di una playlist musicale
- Aggiornamento dell'indirizzo di una persona
- Eliminazione di un post del blog
Perché REST ha sostituito RPC?
Sebbene le REST API Web oggi siano la norma, Remote Procedure Call (RPC) non è scomparso del tutto. Una REST API viene in genere utilizzata nelle applicazioni in quanto è più facile da comprendere e implementare per gli sviluppatori. Tuttavia, RPC esiste ancora e viene utilizzato quando si adatta meglio al caso d'uso.
Oggi sono più popolari le moderne implementazioni di RPC, come gRPC. Per alcuni casi d'uso, gRPC offre prestazioni migliori rispetto a RPC e REST. Consente lo streaming delle comunicazioni client-server anziché il modello di scambio di dati di richiesta e risposta.
Riepilogo delle differenze tra RPC e REST
| RPC |
REST |
|
| In cosa consiste? |
Un sistema consente a un client remoto di chiamare una procedura su un server come se fosse locale. |
Un insieme di regole che definisce lo scambio di dati strutturati tra un client e un server. |
| Usato per |
Esecuzione di operazioni su un server remoto. |
Operazioni di creazione, lettura, aggiornamento ed eliminazione (CRUD) su oggetti remoti. |
| Best fit |
Quando si richiedono calcoli complessi o si attiva un processo remoto sul server. |
Quando i dati e le strutture dati del server devono essere esposti in modo uniforme. |
| Statefulness |
Stateful o stateless. |
Stateless. |
| Formato di trasferimento dei dati |
In una struttura coerente definita dal server e applicata al client. |
In una struttura determinata in modo indipendente dal server. È possibile passare più formati diversi all'interno della stessa API. |
In quale modo AWS può supportare i requisiti API?
Amazon Web Services (AWS) offre una gamma di servizi e strumenti per aiutare i progettisti di API a creare, eseguire e gestire applicazioni e servizi moderni basati su API. Per ulteriori informazioni, leggi come creare applicazioni moderne su AWS.
Ecco alcuni esempi di servizi AWS che possono aiutarti a soddisfare i requisiti delle API:
- Gateway Amazon API consente agli sviluppatori di creare, pubblicare e gestire API su larga scala. Con Gateway API, puoi creare REST API ottimizzate per architetture di microservizi containerizzate e applicazioni Web.
- Elastic Load Balancing (ELB) distribuisce il traffico di rete per migliorare la scalabilità delle applicazioni. Può instradare e bilanciare il carico del traffico gRPC tra microservizi o tra client e servizi abilitati a gRPC. Ciò consente una gestione fluida del traffico gRPC nelle architetture software senza modificare alcuna infrastruttura sottostante per i clienti o i servizi dei clienti.
- Amazon Virtual Private Cloud (Amazon VPC) Lattice è un servizio di rete di applicazioni che connette, monitora e protegge costantemente le comunicazioni tra i tuoi servizi. Scala automaticamente le risorse di calcolo e di rete per supportare carichi di lavoro HTTP, HTTPS e gRPC a larghezza di banda elevata.
Inizia subito a utilizzare le REST API e le API Remote Procedure Call (RPC) su AWS creando un account.
