Em geral, o RPC oferece muito mais integração de idiomas que o REST. Como você mencionou, isso vem com vários problemas em termos de escala, manipulação de erros, segurança de tipo, etc., especialmente quando um único sistema distribuído envolve vários hosts executando código escrito em vários idiomas. No entanto, depois de escrever sistemas de negócios que usam RPC, REST e até ambos simultaneamente, descobri que existem algumas boas razões para escolher RPC sobre REST em certos casos.
Aqui estão os casos em que eu achei o RPC um ajuste melhor:
- Acoplamento apertado. Os componentes (distribuídos) do sistema são projetados para trabalhar juntos, e a alteração de um provavelmente afetará todos os outros. É improvável que os componentes precisem ser adaptados para se comunicar com outros sistemas no futuro.
- Comunicação confiável. Os componentes se comunicarão entre si inteiramente no mesmo host ou em uma rede que provavelmente não apresentará problemas de latência, perda de pacotes, etc.
- Linguagem uniforme. Todos (ou quase todos) os componentes serão escritos em um único idioma. É improvável que componentes adicionais escritos em um idioma diferente sejam adicionados no futuro.
Em relação ao ponto sobre o IDL, em um sistema REST, você também precisa escrever um código que converta os dados nas solicitações e respostas REST para qualquer representação de dados interna que você esteja usando. As fontes IDL (com bons comentários) também podem servir como documentação da interface, que deve ser escrita e mantida separadamente para uma API REST.
Os três itens acima geralmente ocorrem quando você deseja criar um componente de um sistema maior. Na minha experiência, esses componentes geralmente são aqueles em que seus subsistemas precisam falhar independentemente e não causar a falha total de outros subsistemas ou de todo o componente. Muitos sistemas são escritos em Erlang para atingir esses objetivos também e, em alguns casos, Erlang pode ser uma escolha melhor do que escrever um sistema em outro idioma e usar o RPC apenas para obter esses benefícios.
Como a maioria dos problemas de engenharia, não existe uma solução única para o problema da comunicação entre processos. Você precisa observar o sistema que está projetando e fazer a melhor escolha para o seu caso de uso.