RMI 与 REST 服务
我们正在为使用 JSF 开发的门户/Web 客户端开发一项服务。我的建议是将服务公开为 REST，但另一位团队成员说采用 RMI 实现，因为从开发和测试的角度来看，它更容易处理 java 对象。
我的论点是开发和测试工作几乎相同，但我们将获得 REST Web 服务的所有优点。
仅供参考：我们已经有了 REST 设置，因此框架支持无需额外费用。此服务向我们使用 REST api 的智能手机客户端公开。
最后我们的经理决定采用 RMI 方式，但我仍然认为 REST 会是更聪明的方式。
您会选择 REST 还是 RMI？
注意：我的团队成员或经理只是想在这里学习，没有什么可反对的。
We are developing a service for our portal / web client developed using JSF . My advice was to expose the service as REST but another team member said to go with RMI implementation since its easier to deal in java object from development and testing point of view.
My argument was development and testing efforts with be pretty much the same but we will get all the goodness of REST web services.
FYI : We already have REST setup so there is no extra cost in framework support. This services are exposed for our smartphone client who uses REST api.
At the end our Manager decided to go with RMI way but I still think REST would be smarter way.
What would be your choice REST or RMI?
Note : Nothing against my team member or Manager just trying to learn here.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
如果客户端和服务器之间存在防火墙，则 RMI 流量可能会被阻止。 HTTP 流量在大多数防火墙上都是开放的，REST 通过应该没有问题。
If there are firewalls between your client and server, it is likely that RMI traffic might be blocked. HTTP traffic is open on most firewalls and REST should have no problem getting through.
反对 RMI 和 REST/SOAP 等的最大论据是客户端不必是 Java。
如果您的前端可能会从 JSF 更改为 ASP，那么您就会遇到麻烦。
除此之外，RMI 是可行的方法。更好的方法是 EJB（它是 RMI 之上的一层），它具有额外的优势——许多供应商已经实现了 EJB 规范，您可以获得对象池、事务管理等优势。
The biggest argument against RMI and for REST/SOAP etc is that the client does not have to be Java.
If your front-end could change down the road from JSF to ASP, then you'll be in some trouble.
Other than that, RMI is the way to go. An even better way to go is EJB ( which is a layer on top of RMI ) with additional advantages -- lots of vendors already implement the EJB spec, you get the advantages of object pooling, transaction management etc.
是Java中的客户端，使用RMI。但这只是简单的想法。因为它只是一个点对点协议。
如果您有很多读取操作并且喜欢使用 HTTP 技术进行缓存等，那么 REST 作为范例很有趣。接下来您可能可以轻松实现“分页游标”，以便将数据作为小页面发送并添加如何检索的信息下一页。
您的问题基本上被表述为好像是一个技术问题。这是错误的做法。你不应该关心技术，而应该关心系统架构。整个软件系统、它的能力、它的性能、它的扩展、它的配置和它的维护是完全不同的，具体取决于您对 RMI 或 REST 的使用。
Is the client in Java, use RMI. But that is to simple thought. As it is only a point to point protocol.
REST as a paradigm is interesting if you have e.g. many reads and like to use HTTP technologies for caching etc. The next thing is you likely can easy implement "paging cursors" so you send data as a small page and add info how to retrieve the next page.
Your question basically is formulated as if it is a technology question. Which is the wrong approach. You should not bother about technology but about system architecture. The whole software system, its abilities, its performance, its scaling, its configuration and its maintenance is completely different depending on your usage of RMI or REST.