REST vs RPC para desenvolvimento móvel

Como muitos sabem, o desenvolvimento móvel está disparando nos dias de hoje e, acredito, afeta o que codificamos. Para ser específico, estou interessado em desenvolver serviços da web para um aplicativo móvel.

Eu vejo duas arquiteturas possíveis - RPC e REST. Eu desenvolvi os serviços REST e RPC e o que observei é que os serviços RPC são muito mais fáceis de codificar, especialmente em linguagens como PHP. O problema com isso parece ser escalabilidade - o lado do servidor pode facilmente se transformar em confusão quando muitos procedimentos estão presentes.

REST, por outro lado, parece ser muito mais estruturado, o lado do servidor se torna relativamente fácil de manter, mas tem o potencial de dividir dados em vários recursos, o que é ruim para aplicativos móveis (por vários motivos).

Pelo que experimentei, o RPC parece um pouco melhor na maioria dos casos:

• Tanto o cliente quanto o servidor estão preocupados em minimizar o número de procedimentos disponíveis e as chamadas feitas.
• Seguir as regras de arquitetura não contraria as otimizações possíveis.

Eu realmente não espero que alguém me explique o que são REST e RPC, a Web está cheia disso. Quero que as pessoas com experiência no desenvolvimento de aplicativos móveis expressem suas opiniões sobre o uso dessas duas arquiteturas no lado do servidor. Dicas também são bem-vindas (quem não gosta de dicas, não é?).

Há pouca diferença, o RPC tende a ser mais protocolos binários do que o REST, mas esse não precisa ser o caso. Além disso, o RPC tende a ser implementado como um único ponto de procedimento por chamada, mas novamente isso não precisa ser - você pode implementar um único procedimento RPC que usa um verbo no estilo REST como o primeiro argumento. Às vezes, o RPC tem uma abordagem semestral, mas, novamente, isso não precisa ser o caso se você passar um 'cookie' a cada chamada.

Atualmente, tudo se resume ao suporte ao desenvolvimento, e há mais APIs REST para linguagens baseadas na Web e, portanto, as pessoas usam o REST. Se você está adotando uma visão de desenvolvimento mais centrada no usuário, provavelmente seria melhor usar um mecanismo RPC, aproveitando a flexibilidade para fornecer um protocolo binário mais compactado e implementá-lo como desejar - procedimento único que direciona para uma rotina com base em um ID ou 'verbo' e fica sem estado de estado ao passar um ID. Tudo isso pode ser implementado para parecer muito com REST, mas com sobrecarga significativamente menor.

Existem vários sistemas RPC, tente buffers de protocolo ou economia para seu aplicativo móvel.

Você pode dar uma olhada neste artigo da Netflix sobre o redesenho da API: http://techblog.netflix.com/2012/07/embracing-differences-inside-netflix.html

TL; DR:

• O REST em geral causa APIs chatty: se uma operação precisar manipular vários recursos, você precisará de várias chamadas (ou seja, lento!)
• Uma API não mapeia bem para diferentes consumidores, e é por isso que a Netflix está transferindo parte do código do cliente para o servidor: cada consumidor pode fornecer sua própria camada de adaptador / orquestração no servidor para otimizar o acesso da API aos diferentes consumidores.

Nota pessoal:

• Por favor, não associe o RPC aos protocolos corporativos SOAP / CORBA / RMI de estilo antigo. Por exemplo, JSON-RPC é um protocolo muito simples, elegante e ágil para executar RPC, que você deve considerar definitivamente.
• O REST é perfeito para APIs CRUD. No entanto, se sua API for muito orientada para a ação, talvez seja difícil mapear isso nos verbos / pontos de extremidade REST.