我們正在爲使用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