對象代理的XML-RPC

Question

是否有任何理由不使用XML-RPC作爲對象代理服務器/客戶端體系結構？也許像「不，它已經過時了，現在有X」。

給你更多的細節：我想建立一個框架，允許標準化的交互和許多小工具（例如命令行工具）之間交換結果。如果有人想整合另一個工具，她會爲此寫一個包裝。包裝可以，例如，例如，將工具的STDOUT轉換爲該體系結構可用的對象。

目前我正在考慮用Python編寫概念驗證服務器。稍後它可以用C/C++重寫。爲了確保客戶端可以使用盡可能多的語言編寫，我想到了使用XML-RPC。由於服務器不應該太複雜，因此CORBA似乎太過於臃腫。

謝謝你的建議和意見， 賴

Answer 1

XML-RPC有很多爲它去。創建和使用起來非常簡單，易於理解並易於編碼。

我會說避免像瘟疫一樣的SOAP和CORBA。它們太複雜，而且使用SOAP會產生無窮無盡的問題，因爲只有來自單個供應商的實現往往會很好地交互 - 可能是因爲標準的複雜性導致了不同的解釋。

您可能想要考慮一個RESTful架構。不能直接比較REST和XML-RPC。 XML-RPC是RPC的特定實現，而REST是一種架構風格。 REST並沒有要求任何東西 - 這是更多的一種方式與一系列的約定和建議。 REST可以看起來很像XML-RPC，但它不一定非要。

看看http://en.wikipedia.org/wiki/Representational_State_Transfer和一些外部鏈接的文章。

REST的目標之一是通過在HTTP上創建一個無狀態接口，允許使用標準的緩存機制和負載平衡機制，而無需發明新的方式來完成HTTP已經很好解決的問題。

閱讀了關於REST的文章後，您可能會認爲對於您的項目來說XML-RPC仍然是最好的解決方案，根據您嘗試實現的目標，這將是一個完全合理的結論。