O REST foi projetado para a web e a web foi projetada para o REST. Os dois apenas se encaixam. A tese de doutorado de Roy Fielding em 2000, Architectural Styles e Design of Network-Based Architectures, definiu e introduziu o termo REST , e há uma interação significativa entre a web e o REST: Roy Fielding trabalhou no HTTP / 1.1, do qual é o autor principal, e ele usou o que aprendeu lá para descrever o REST em sua dissertação.
Portanto, a simples razão pela qual a web e o REST se combinam tão bem é que a definição de REST foi extraída de como a web funciona e a web é uma implementação do REST.
É por isso que o REST é adequado para serviços da Web e aplicativos da Web: porque você simplesmente faz as mesmas coisas que já comprovadamente funcionam na Web "humana" e as aplica à Web da "máquina".
O grande problema do RPC (dependendo da implementação exata ) está basicamente nas falácias da computação distribuída , que são explicadas em mais detalhes neste whitepaper por Arnon Rotem-Gal-Oz :
- A rede é confiável
- Latência é zero
- A largura de banda é infinita
- A rede está segura
- A topologia não muda
- Existe um administrador
- O custo de transporte é zero
- A rede é homogênea
Essas são todas as suposições que os recém-chegados costumam fazer quando começam a criar sistemas distribuídos. Claro, todos eles são falsos. E você precisa levar todos eles em consideração ao criar sistemas distribuídos.
O problema com muitas implementações de RPC é que eles tentam fazer chamadas remotas parecerem chamadas locais. Mas eles não são nada parecidos:
- uma chamada local nunca falha; a sub - rotina que você chamou pode falhar, mas a chamada em si nunca falha - uma chamada remota pode se perder na rede
- uma chamada local é instantânea; a sub - rotina que você chamou pode ser executada por um longo período de tempo (ou mesmo para sempre, se ficar presa em um loop infinito), mas a chamada em si não leva tempo algum (bem, um punhado de instruções da CPU, no máximo, menos se a chamada for inline, mas é muito rápido) - uma chamada remota pode ficar presa na rede por um longo tempo
- se a sub-rotina retornar normalmente, o resultado sempre volta - com uma chamada remota, o resultado pode se perder na rede
- os retornos são instantâneos - resultados remotos podem viajar na rede por um longo tempo
- se eu chamar uma sub-rotina uma vez, ela será executada exatamente uma vez - uma chamada remota poderá se perder na rede ou duplicada, de modo que a rotina remota possa ser executada entre 0 e qualquer número de vezes
- Eu recebo exatamente um resultado - um resultado remoto pode ser perdido ou duplicado, e você pode obter o resultado 0 ou mais vezes
- se eu chamar uma sub-rotina duas vezes, obtive dois resultados e o resultado da primeira chamada antes do resultado da segunda chamada - você provavelmente já pode adivinhar agora: com o RPC, você pode recuperar nenhum resultado ou apenas o primeiro , ou apenas o segundo, ou o segundo antes do primeiro, ou o primeiro pode ser perdido e você recebe o segundo duas vezes, ou o contrário, e assim por diante ...
- se eu ligar
ae depois bretornar o resultado de ae, em seguida, o resultado de b - esta é apenas uma versão mais geral do ponto anterior, com o RPC, você pode obter qualquer uma das duas respostas 0 ou mais vezes em qualquer ordem
Você terá que lidar com todos os itens acima para uma chamada remota. Mas se sua estrutura torna as chamadas remotas indistinguíveis das chamadas locais, você não pode , porque não sabe quais são as chamadas remotas. A estrutura pode tentar lidar com tudo isso para você, mas o problema é: a estrutura não sabe tanto sobre o seu sistema quanto você. Não sabe se há chamadas em que realmente não importa se uma se perde de vez em quando. Portanto, a estrutura deve ser muito defensiva, e isso é caro em termos de latência e largura de banda.
Especialmente porque a estrutura realmente não pode protegê-lo. O teorema do CAP diz que um sistema distribuído não pode ser consistente, disponível e tolerante a partições ao mesmo tempo; mais precisamente, diz que, uma vez que uma partição ocorre, o sistema não pode continuar consistente e disponível, ele deve escolher uma (ao contrário da crença popular, o teorema não diz que você não pode ter todas as três quando o sistema está em execução) normalmente, você pode ter todos os três; mas depois de ter uma partição, você deve escolher uma das outras duas). O teorema do PACELC estende o teorema do CAP, mostrando que, mesmo quando o sistema está funcionando, você precisa compensar a latência versus a consistência.
Essas são trocas importantes das quais a estrutura praticamente não pode protegê-lo, uma vez que são específicas do domínio e importantes para o design principal.
Compare isso com uma abordagem como Erlang do, que faz trabalho: em Erlang, toda mensagem envia são tratados como remota, mesmo se eles são local. Isso significa que você está sempre preparado para lidar com todos os problemas acima (e muitos mais). Para processos locais, estes não representam um pouco de uma sobrecarga, porém. Para ajudar com isso, existem muitas ferramentas, estruturas, bibliotecas, padrões e expressões idiomáticas para lidar com a manipulação e supervisão de erros.
Você não descreveu como sua estrutura RPC funciona em particular e qual linguagem ou bibliotecas você está usando, mas eu tenho uma forte suspeita de que ela pertença ao tipo "fingir que a rede não existe". Aqueles simplesmente não funcionam. Não há problema em remover a distinção entre chamadas locais e remotas tratando tudo como uma chamada remota . Ao contrário, abstrai demais a rede: a rede faz parte do seu sistema; se você abstrai, abstrai algo que realmente precisa saber.
Agora, se você precisa usar especificamente o REST ou não, essa é uma pergunta totalmente diferente. Como expliquei acima, a web foi projetado para descanso e repouso foi concebido para a web, assim que os dois fazem fazem sentido juntos, mas você pode usar outros estilos arquitectónicos, se você quiser. Mas pelo menos parte de sua pergunta era sobre "por que não RPC" e expliquei os motivos acima, mais precisamente expliquei por que o tipo de RPC que suspeito que você está usando pode causar problemas.