Quando gli approcci RPC-ish sono più appropriati di REST?

Dopo aver visto questo discorso su REST, Reuse e Serendipity di Steve Vinoski, mi chiedo se ci siano casi aziendali in progetti greenfield per configurazioni (XML-) RPC-ish, che REST non potrebbe risolvere in modo migliore.

Alcuni problemi RPC menziona:

• Focus sulla lingua (adatta il sistema distribuito alla lingua, non viceversa)
• "Renderlo locale" (e far fronte a errori e latenza come eccezioni anziché come regola)
• inteso come indipendente dalla lingua, ma ha ancora "chiamate di funzione" tra le lingue come ingrediente principale
• Caldaia IDL
• Illusione della sicurezza del tipo
• e qualche altro ...

Giusto per drammatizzarlo un po ', alcuni risultati di Google Instant per RPC vs REST:

In generale, RPC offre molto più di un'integrazione linguistica rispetto a REST. Come hai detto, questo comporta una serie di problemi in termini di scala, gestione degli errori, sicurezza dei tipi, 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 persino entrambi contemporaneamente, ho scoperto che ci sono alcuni buoni motivi per scegliere RPC piuttosto che REST in alcuni casi.

Ecco i casi in cui ho trovato RPC per adattarsi meglio:

• 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 dovranno essere adattati per comunicare con altri sistemi in futuro.
• Comunicazione affidabile. I componenti comunicheranno tra loro interamente sullo stesso host o su una rete che è improbabile che si verifichino problemi di latenza, perdita di pacchetti, ecc. (Ciò significa comunque che è necessario progettare il sistema per gestire questi casi).
• Linguaggio uniforme. Tutti (o principalmente tutti) i componenti saranno scritti in una sola lingua. È improbabile che ulteriori componenti scritti in una lingua diversa vengano aggiunti in futuro.

Per quanto riguarda il punto su IDL, in un sistema REST devi anche scrivere codice che converta i dati nelle richieste REST e le risposte a qualunque rappresentazione interna dei dati che stai utilizzando. Le fonti IDL (con buoni commenti) possono anche fungere da documentazione dell'interfaccia, che deve essere scritta e gestita separatamente per un'API REST.

I tre elementi precedenti si verificano spesso quando si desidera creare un componente di un sistema più grande. Nella mia esperienza, questi componenti sono spesso quelli in cui i loro sottosistemi devono poter fallire in modo indipendente 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 può essere una scelta migliore che scrivere un sistema in un'altra lingua e usare RPC solo per ottenere questi benefici.

Come la maggior parte dei problemi di ingegneria, 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 di REST quando i prodotti vengono ridimensionati in un datacenter e si sta ottenendo elevata disponibilità e bilanciamento del carico.

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

In realtà puoi avere entrambi. Plugin come RestRPC for Grails forniscono annotazioni che intercettano le chiamate ai tuoi metodi e le gestiscono in modo riposante, permettendoti di averne quante ne vuoi (che sarebbe molto simile a RPC).