REST è stato progettato per il Web e il Web è stato progettato per REST. I due si adatteranno insieme. La tesi di dottorato di Roy Fielding del 2000, Stili architettonici e la progettazione di architetture software basate su rete, hanno definito e introdotto il termine REST , e vi è una significativa interazione tra il web e il REST: Roy Fielding ha lavorato su HTTP / 1.1, di cui è l'autore principale, e ha usato quello che ha imparato lì per descrivere REST nella sua tesi di laurea.
Quindi, la semplice ragione per cui il web e il REST vanno così bene insieme è che la definizione di REST è stata estratta da come funziona il web, e il web è un'implementazione di REST.
Ecco perché REST si adatta perfettamente ai servizi Web e alle app Web: perché fai semplicemente le stesse cose che hanno già dimostrato di funzionare nel web "umano" e le applichi al web "macchina".
Il grosso problema con RPC (a seconda dell'esatta implementazione) risiede essenzialmente nelle Fallacie del calcolo distribuito , che sono spiegate più in dettaglio in questo white paper di Arnon Rotem-Gal-Oz :
- La rete è affidabile
- La latenza è zero
- La larghezza di banda è infinita
- La rete è sicura
- La topologia non cambia
- C'è un amministratore
- Il costo del trasporto è zero
- La rete è omogenea
Questi sono tutti i presupposti che i nuovi arrivati fanno in genere quando iniziano a creare sistemi distribuiti. Certo, sono tutti falsi. E devi tenerne conto tutti durante la creazione di sistemi distribuiti.
Il problema con molte implementazioni RPC è che provano a far apparire le chiamate remote come chiamate locali. Ma non sono niente simili:
- una chiamata locale non fallisce mai; la subroutine che hai chiamato potrebbe non riuscire, ma la chiamata stessa non lo fa mai - una chiamata remota potrebbe perdersi sulla rete
- una chiamata locale è istantanea; la subroutine che hai chiamato può funzionare a lungo (o anche per sempre se rimane bloccata in un loop infinito), ma la chiamata stessa non richiede affatto tempo (beh, una manciata di istruzioni CPU al massimo, meno se la chiamata è in linea, ma è molto veloce) - una chiamata remota potrebbe rimanere bloccata sulla rete per molto tempo
- se la subroutine ritorna normalmente, il risultato ritorna sempre - con una chiamata remota, il risultato potrebbe perdersi sulla rete
- i ritorni sono istantanei - i risultati remoti possono viaggiare sulla rete per molto tempo
- se chiamo una subroutine una volta, verrà eseguita esattamente una volta: una chiamata remota potrebbe andare persa sulla rete o duplicata in modo che la routine remota possa essere eseguita tra 0 e un numero qualsiasi di volte
- Ricevo esattamente un risultato: un risultato remoto potrebbe andare perso o duplicato, quindi potresti ottenere il risultato 0 o più volte
- se chiamo una subroutine due volte, ottengo due risultati e ottengo il risultato della prima chiamata prima del risultato della seconda chiamata - probabilmente ora puoi indovinarlo: con RPC, potresti non ottenere alcun risultato, o solo la prima , o solo il secondo, o il secondo prima del primo, o il primo potrebbe andare perso e si ottiene il secondo due volte, o viceversa, e così via ...
- se chiamo
ae poi b, ottengo indietro il risultato ae poi il risultato di b - questa è solo una versione più generale del punto precedente, con RPC, puoi ottenere una delle due risposte 0 o più volte in qualsiasi ordine
Si dovrà fare i conti con tutto quanto sopra per una chiamata remota. Ma se il tuo framework rende le chiamate remote indistinguibili dalle chiamate locali, allora non puoi , perché non sai quali sono le chiamate remote. Il framework potrebbe provare a gestirli tutti per te, ma il problema è: il framework non conosce tanto il tuo sistema quanto te. Non sa se ci sono chiamate in cui in realtà non importa se ci si perde una volta ogni tanto. Quindi, il framework deve essere molto difensivo, e questo è costoso in termini di latenza e larghezza di banda.
Soprattutto perché il framework in realtà non può proteggerti. Il teorema della PAC afferma che un sistema distribuito non può essere coerente, disponibile e tollerante alla partizione allo stesso tempo; più precisamente, dice che una volta che si verifica una partizione, il sistema non può continuare ad essere sia coerente che disponibile, deve sceglierne una (contrariamente alla credenza popolare, il teorema non dice che non si possono avere tutte e tre, quando il sistema è in esecuzione normalmente, puoi averli tutti e tre; ma una volta che hai una partizione, devi scegliere una delle altre due). Il teorema PACELC estende il teorema della PAC dimostrando che anche quando il sistema funziona, è necessario bilanciare Latenza vs. Coerenza.
Questi sono importanti compromessi da cui il framework praticamente non può proteggerti, dal momento che sono specifici del dominio e importanti per la progettazione di base.
Questo contrasto con un approccio come Erlang di, che fa il lavoro: in Erlang, tutto messaggio invia sono trattati come a distanza, anche se sono locali. Ciò significa che sei sempre pronto ad affrontare tutti i problemi di cui sopra (e molti altri). Per i processi locali, tuttavia, ciò comporta un certo sovraccarico. A tale scopo, esistono numerosi strumenti, framework, librerie, schemi e modi di dire per gestire la gestione e la supervisione degli errori.
Non hai descritto come funziona il tuo framework RPC, e quale lingua o librerie stai usando, ma ho il forte sospetto che appartenga al precedente tipo "fingere che la rete non esista". Quelli semplicemente non funzionano. E ' giusto per rimuovere la distinzione tra chiamate locali e remoti trattando tutto ciò come a distanza di chiamata. Farlo il contrario abstracts troppo: la rete è parte del vostro sistema, se astratto via, è astratta via qualcosa che in realtà bisogno di conoscere.
Ora, se devi usare specificamente REST o meno, questa è una domanda completamente diversa. Come ho spiegato in precedenza, il web è stato progettato per il riposo e il riposo è stato progettato per il web, così i due fanno un senso insieme, ma è possibile utilizzare altri stili architettonici, se si vuole. Ma almeno una parte della tua domanda riguardava il "perché non l'RPC", e ho spiegato i motivi sopra, più precisamente ho spiegato perché il tipo di RPC che sospetto che stai usando potrebbe metterti nei guai.