Quando l'approccio RPC-ish è più appropriato di REST?

In generale, RPC offre un'integrazione linguistica molto maggiore rispetto a REST. Come già accennato, questo comporta una serie di problemi in termini di scala, gestione degli errori, sicurezza del tipo, ecc., Specialmente quando un singolo sistema distribuito coinvolge più host che eseguono codice scritto in più lingue. Tuttavia, dopo aver scritto sistemi aziendali che utilizzano RPC, REST e anche entrambi contemporaneamente, ho scoperto che ci sono alcuni buoni motivi per scegliere RPC su REST in alcuni casi.

Ecco i casi in cui ho trovato un RPC più adatto:

• Accoppiamento stretto. I componenti (distribuiti) del sistema sono progettati per funzionare insieme e cambiarne uno avrà probabilmente un impatto su tutti gli altri. È improbabile che i componenti debbano essere adattati per comunicare con altri sistemi in futuro.
• Comunicazione affidabile. I componenti comunicano tra loro interamente sullo stesso host o su una rete che non presenta problemi di latenza, perdita di pacchetti, ecc. (Ciò significa che devi progettare il tuo sistema per gestire questi casi, comunque.)
• Lingua uniforme. Tutte le componenti (o quasi tutte) verranno scritte in una sola lingua. È improbabile che componenti aggiuntivi scritti in una lingua diversa verranno aggiunti in futuro.

Riguardo al punto su IDL, in un sistema REST è anche necessario scrivere codice che converta i dati nelle richieste REST e le risposte a qualsiasi rappresentazione di dati interna che si sta utilizzando. Le fonti IDL (con buoni commenti) possono anche servire come documentazione dell'interfaccia, che deve essere scritta e gestita separatamente per un'API REST.

I tre elementi precedenti si verificano spesso quando si sta cercando di creare un componente di un sistema più grande. Nella mia esperienza, questi componenti sono spesso quelli in cui i loro sottosistemi devono essere in grado di fallire indipendentemente e non causare il fallimento totale di altri sottosistemi o dell'intero componente. Molti sistemi sono scritti in Erlang per raggiungere anche questi obiettivi, e in alcuni casi Erlang potrebbe essere una scelta migliore rispetto a scrivere un sistema in un'altra lingua e usare RPC solo per ottenere questi benefici.

Come la maggior parte dei problemi di progettazione, non esiste un'unica soluzione al problema della comunicazione tra processi. Devi guardare il sistema che stai progettando e fare la scelta migliore per il tuo caso d'uso.

Ci sono alcuni importanti vantaggi del REST quando i prodotti vengono scalati su un data center e si sta eseguendo un'elevata disponibilità e bilanciamento del carico.

Tuttavia, pensa a un progetto su scala più piccola. Hai bisogno di un webservice che avrà qualche centinaia di richieste all'ora? WCF si occupa di tutti i problemi di trasporto. Dispone di una comoda interfaccia per l'invio di oggetti attraverso la rete e consente di configurare, crittografare e certificare la connessione di rete con la programmazione zero utilizzando solo il file application.config.

In realtà puoi averli entrambi. Plugin come RestRPC for Grails forniscono annotazioni che intercettano le chiamate ai tuoi metodi e le gestiscono restful e ti permettono di avere quante ne vuoi (il che sarebbe molto simile a RPC).