只是尋找關於Web服務接口設計最佳實踐的一些反饋。Web服務接口 - 複雜類型作爲參數？
我有兩種選擇：
選項1
public string GetSomeData(SomeCriteriaClass criteria);
其中SomeCriteriaClass定義爲：
public int ID;
public string Name;
public string Property2; etc.
選項2
public string GetSomeData(int id, string name, string property2)
哪個是首選選項？這似乎是設計模式的衝突 - 第一種是將類中的參數封裝起來，另一類是保持Web服務接口的靈活性和開放性。
第二個問題是 - 如果我們選擇Option1 - 你如何通過URL調用它？
謝謝
你可以用硬性的方式去實現選項＃1，使用SOAP。使用SOAP，您可以定義複雜的數據類型。另一方面，您可以像選項＃2那樣使用「黑客」方法，使用REST並僅對URL或HTTP POST消息中的參數進行編碼。
術語「網絡服務」通常用於兩種不同的事情。
一種技術：使用HTTP（S）作爲進程間通信的協議。
一種架構方法：面向服務的體系結構。
如果我們談論的Web服務只是一個技術，那麼你有很多選擇：你可以使用HTTP GET（這是使用網址參數的一個）或HTTP POST（該數據在HTTP消息的主體）。對於HTTP POST，有效載荷可以是SOAP或任何propriatery的東西。
如果我們談論的是面向服務的方法和Web服務作爲工具，那麼HTTP + SOAP是最標準的方法。
如果我們考慮一個Web服務方法只是一個服務操作的實現，然後使用下面這強調了這一方法的簽名：
public FooResponse FooOperation(FooRequest request);
這意味着操作有一個請求和響應文件（即使其中任何一個都是空的），您可以分離服務合同（您公開哪些操作）和數據合同（您如何撰寫請求和響應消息）。請參閱此文章爲更多細節吧：Principles of Service Design Service Patterns and Anti-Patterns
結論：
感謝這個，我一定會讀到SOA最佳實踐。當你說它是「不被推薦」的時候 - 它仍然不是特別壞，是嗎？！例如，我沒有在該鏈接中看到任何將其描述爲反模式的內容。 – Duncan 2009-05-19 09:48:11
選項1公共字符串GetSomeData（SomeCriteriaClass條件）; 是很好的實現webservice的方法，因爲你使用SOAP和麪向文檔的術語。而option2則是針對基本的java開發者不太專心的設計模式。
讓我們的場景 - 使用選項2之後，假設你婉在SomeCriteriaClass.java增加3個varibale那麼，有什麼辦法，你會選擇.. 3個參數添加到GetSomeData（）方法或SomeCriteriaClass.java聲明。
一個好的設計模式追隨者，選擇聲明SomeCriteriaClass.java不添加在GetSomeData（）中。
爲什麼說選項2「保持Web服務界面的靈活性和開放性」？這意味着對數據參數的任何更改都會影響API的聲明，而在選項1中它只會影響「參數類」聲明（當然還有調用代碼）。 – 2009-05-19 08:34:30
對不起，這是完全正確的，而不是靈活和開放，應該看到「可見和直接」。我不知道如何通過URL來調用通過複雜類型傳遞的Web服務 - 這對我稍有影響。是否有缺點，它是否更復雜？ – Duncan 2009-05-19 09:15:15