Por que o REST é comumente usado em vez de mecanismos do tipo RPC em aplicativos da Web?

Comecei muito recentemente em uma empresa que usa uma estrutura personalizada bastante incomum para seus aplicativos da web, pelo menos em comparação com as estruturas típicas de aplicativos da web que conheço. Em vez de um serviço da Web RESTful, um mecanismo RPC é usado para se comunicar com o servidor.

A comunicação com o servidor parece uma simples chamada de função, mas a função é executada no servidor, não no cliente. No lado do servidor, há uma maneira de definir quais funções o cliente pode chamar. Os detalhes de como isso é traduzido em solicitações http são abstraídos completamente.

Eu só usei isso há pouco tempo, mas parece bastante conveniente. Mas estou me perguntando que desvantagens dessa abordagem estão faltando. Todo mundo parece estar fazendo isso de maneira diferente, o que geralmente é um sinal para mim de que eu posso estar fazendo algo estúpido ou brilhante, com chances muito maiores no primeiro.

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 :

1. A rede é confiável
2. Latência é zero
3. A largura de banda é infinita
4. A rede está segura
5. A topologia não muda
6. Existe um administrador
7. O custo de transporte é zero
8. 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.

Já existem várias boas idéias nos comentários, que repetirei aqui:

1. O RPC é tipicamente específico da tecnologia.
2. O que mais interessa aos desenvolvedores é JSON, não REST.

JSON tem algumas qualidades muito boas. É simples, fácil para um ser humano ler, fácil para um computador analisar e o Javascript reconhece-o instantaneamente de forma nativa (sendo, sabe, a notação de objeto Javascript ).

Se você deseja renunciar a restrições como o REST, pode fazer quase tudo o que quiser com o JSON, incluindo chamadas de procedimento remoto. Tudo que você precisa fazer é estabelecer um protocolo adequado. De fato, esse protocolo já existe: JSON-RPC.

--> {"jsonrpc": "2.0", "method": "subtract", "params": [42, 23], "id": 1}
<-- {"jsonrpc": "2.0", "result": 19, "id": 1}

RPC e REST são apenas abordagens diferentes com prós e contras e ambos têm valor dependendo do contexto. É melhor descrever o REST para trabalhar com os recursos, enquanto RPC é mais sobre as ações. Os clientes RPC são fortemente acoplados à implementação do serviço de várias maneiras e torna-se muito difícil alterar a implementação do serviço sem interromper os clientes.