API設計：公開XML或對象

Question

我們正在着手新的中間層服務，它允許內部客戶端系統在一些底層數據存儲中創建和更新和查詢記錄。該服務將聚合多達3個獨立的基礎數據存儲。對於這個問題的目的，假設：

數據存儲＃1：專有XML數據庫。
數據存儲＃2：現成的關係數據庫。
數據存儲＃3：平面文件存儲（以二進制形式存儲的文件）。

客戶端將不知道（也不在乎）的數據存儲他們查詢/ udpating。新服務將作出這一決定。我的問題是：我的API應該公開XML還是對象？例如。新的API將有一個添加方法。假設我們的系統是汽車的存儲系統，那麼API的加載方法可能如下：

AddNewCar(CarObject car) 

或者，它可能是這樣的：

AddNewCar(string carXml) 

現在，儘管第2方法在輸入時很弱類型化，XML將立即針對架構進行驗證，作爲最低限度。

新的服務將在C＃編寫（不是哪個版本尚未決定，但可能是3/3.5與WCF）。 API的客戶端可以是C＃/ VBA/VB.Net/C++/Java）。

更多詳情請讓我知道。謝謝

---

更新：請注意，API也將通過消息總線發佈XML。例如。當添加新車時，汽車XML將會發布，以便任何對新車感興趣的人都會收到通知。

Answer 1

我想說暴露一個對象的API。雖然不是由於上述另一篇文章中提到的原因 - 即暴露XML導致固定格式更難以改變。

可以說，強類型業務對象的API和XML一樣難以改變 - 兩者都需要重新編譯和重新構建。所以這不是你丟棄XML的原因。

原因 - IMNSHO - 是抽象層次的原因。在API級別，您正在談論哪些業務對象或服務可以對其他業務對象執行什麼操作。因此，API必須根據業務對象進行討論。

正如在另一篇文章中已經提到的那樣，您可以隨時使用XML表示揹回業務對象。將業務對象和服務的XML表示保持在較低的抽象級別，以便您的API爲您提供XML的所有靈活性，同時允許您構建具有良好語義的更高級別的API。

Answer 2

當然，stongly類型的方法將是從最終用戶開發人員的角度這是我寧願最簡單的。但是，如果最終所有內容都在幕後轉換爲Xml，或者您不確定您的客戶將採取何種方法，我肯定會建議您同時支持這兩種方法。

Answer 3

，因爲這解決您的格式和未來的任何決定，你可能會面臨基礎設施方面你不應該暴露XML。我會一直走強類型的路線，以確保您正確地抽象您的實施遠離使用。

如果您採用XML路線並通過開發的一部分找出XML由於某種原因而必須更改，那麼要改變API的所有用法來糾正這個問題要比如果您強烈鍵入API並隱藏對象後面的XML細節。

Answer 4

您應該使用對象創建API並在需要時利用WCF提供XML API。

Answer 5

您應該使用Objects創建一個API，然後圍繞該API創建一個Web服務接口（例如，對於Java，您將在接口上使用java2wsdl，然後使用wsdl2java創建一個框架服務器端實現或客戶端實現，我相信WCF中存在一個等價的方法），所有其他系統都可以查詢。

當你具備多語言的客戶端，我認爲Web服務是您最佳的選擇，（忽略了業務邏輯的實現），只在你的API上工作幾分鐘。您可以將您的wsdl或xsd文件分發給所有客戶端軟件的開發人員，然後他們可以使用它們簡單快速地與您的系統連接。