我们正在为使用JSF开发的门户/ Web客户端开发服务。我的建议是将该服务作为REST公开，但另一个团队成员则表示将采用RMI实现，因为从开发和测试角度来看，更容易处理java对象。RMI vs REST服务
我的观点是开发和测试工作几乎完全相同，但我们将获得REST Web服务的所有优点。
仅供参考：我们已经安装了REST，因此在框架支持中没有额外的成本。此服务针对使用REST API的智能手机客户端提供。
最后，我们的经理决定采用RMI方式，但我仍然认为REST会是更聪明的方式。
什么是您的选择REST或RMI？
注意：没有任何反对我的团队成员或经理试图在这里学习。
反对RMI和REST/SOAP等的最大理由是客户端不一定是Java。
如果你的前端可能会改变从JSF到ASP的道路，那么你会遇到一些麻烦。
除此之外，RMI是要走的路。更好的方法是EJB（它是RMI之上的一层），并具有其他优势 - 许多供应商已经实现了EJB规范，您可以获得对象池，事务管理等的优势。
如果您的意思是EJB Enterprise Java Beans，那么我不同意，如果您只需要RMI，那么执行与EJB有关的任何操作将会是一项巨大的开销。 –
如果有是客户端和服务器之间的防火墙，可能会阻止RMI流量。 HTTP流量在大多数防火墙上都是开放的，REST应该没有问题。
如果您将软件卖给公司，这可能是一个大问题 - 他们不喜欢为RMI开放端口，但是，嘿，他们会让您通过HTTP（S）隧道传输任何东西！ – SteveD
您也可以通过HTTP执行RMI。 –
是Java中的客户端，使用RMI。但那是简单的想法。因为它只是一个点对点协议。
REST作为一个范例是有趣的，如果你有例如许多读取并喜欢使用HTTP技术进行缓存等。接下来的事情是，您可能可以轻松实现“分页游标”，因此您可以将数据作为小页面发送，并添加如何检索下一页的信息。
你的问题基本上被表述为如果它是一个技术问题。这是错误的方法。你不应该为技术而关心系统架构。根据您对RMI或REST的使用情况，整个软件系统，其能力，性能，扩展性，配置和维护都是完全不同的。
没有足够的信息给出明确的答案，但是如果你已经有了一个REST API，那么你的经理应该有很好的理由为混合添加另一个远程选项。 – SteveD
如果你在家里跑步，RMI很好。一般互联网上的任何客户端/服务器都应该使用现代的web服务协议。 – jtahlborn