我们仍在尝试在实现REST web服务与使用RPC之间做出决定。 Googles eclipse插件使创建RPC服务变得非常容易，这是RPC方式的主要吸引力。 但是，REST服务似乎更容易修改，恕我直言，并且还会允许未来的iOS客户端进行很少或不需要返工的连接。 我可能会担心的一个问题，也许这是RPC的问题，或者实际上任何客户端 - 服务器模型都是如何修改现有服务并允许旧客户端继续工作，同时允许新客户端使用新功能。 我的意思是，您可以指向我在修改Web服务时应该注意的任何事情，以免破坏现有客户端或强制他们升级。你有任何链接，将涵盖这一点，将不胜感激REST webservice与Android客户端vs RPC
这里几个想法。首先，正如我在类似的问题中指出的那样，比较REST和RPC并没有什么意义。 REST是一组可以强加在接口上的约束来实现一组特定的目标，并且RPC接口实际上可以是RESTful。有关更多信息，请参阅this博客文章。
对于第二部分的问题，你是正确的，在一个自定义的RPC接口中，客户端必须知道它调用的是什么方法，这意味着API会破坏对所公开的过程的更改，从而推出一个新的该服务的版本更具挑战性（而在RESTful接口中，法律行为通常全部由服务器控制）。我链接的博客文章也对此进行了详细介绍。
并行推出多个服务版本的一种方法是在生产多租户中滚动服务版本，并根据任意客户端元数据将请求分派到正确的服务版本。例如，如果您的服务通过一个Servlet暴露的RPC网络API，你可以：
在大多数客户机/服务器方案的客户端的多个版本将在野外随时存在，因此无需服务器控制法律行动最好的解决方案是，同时旧版本的服务器上并行运行多个版本客户端已被弃用。