因此，我對Web服務有點新，最近出現了一種情況，我們向返回給客戶端的數據類型添加了一個元素。客戶抱怨說，這打破了他們的實施，因爲它窒息了它沒有預料到的新元素。 （我們通過Axis2提供服務）。向後兼容性和Web服務
對我來說，這似乎是一個無害的變化，客戶端應該能夠正常處理（我已經與一些非Web服務框架一起添加可選信息是完全可以接受的）。我可以理解，如果我們刪除或重命名某些會導致客戶端問題的字段。
基本上我會期望wsdl的行爲就像一個接口。如果我們做了一個基本上是這個接口的子類型的改變，我希望客戶能夠愉快地忽略無關的元素。這僅僅是網絡服務的一個短暫來臨，還是有一種對服務進行被動更改的理智方式，以便新客戶可以獲得額外數據，而舊客戶可以在閒暇時進行更新？
WSDL實際上充當合同比界面更。 WSDL準確描述了操作期望「接收」的內容以及它期望「返回」的內容。與此最接近的比喻是C在不改變函數本身的情況下更改函數的原型，它們不會匹配並導致問題。
更具體的WSDL是你「保證」到位的行爲越多。
如果您需要在返回數據的靈活性（即添加/刪除字段等），你可以執行下列操作之一：
2有更多的風險，但可以使用XSD或其他技術進行管理。您的特定項目要求將決定什麼是可接受的。
在過去，當處理暴露的WebService API時，我一直使用日期版本管理原則。不幸的是，你必須處理向後公開的任何API的向後兼容性，一旦你退出「測試」模式（有時甚至是那樣）。
我們所做的事情非常簡單;當天的新API發佈，我們會創建一個文件夾結構如下所示：
http://mydomain.com/path/to/service/2009/12/17/servicename.svc
這樣，我們就知道哪個版本是最新的只是通過檢查文件夾結構，和我們的客戶不會有擔心突破變化，直到他們準備升級。爲我們工作就像一個冠軍;我可能已經改變的唯一事情是使用一個單一的文件夾，這樣他們會更容易查看全部一起：
http://mydomain.com/path/to/service/2009-12-17/servicename.svc
我做了一件非常相似的事情，除了我更喜歡使用明確的版本號（例如http：// http：//example.com/ServiceName/1.0/Service/）並且只在API更改時才使用它一種非向後兼容的方式。 – 2010-02-09 10:31:27
WSDL實際上是您的Web服務發佈的SOAP接口。許多客戶端使用它來生成他們的客戶端代理，這些客戶端代理以他們選擇的編程語言公開所有webservice方法。這些代碼生成的客戶端大多非常脆弱，如果他們看到一個他們不認識的元素（即它不在WSDL中）而不是忽略它，就會選擇拋出異常。有些人更放鬆，他們真正使用的是客戶端技術，微軟新的DataContract在其客戶端擁有IExtensibleData接口，專門存儲他們無法識別的數據，因此他們將很大程度上忽略未知元素。
SOAP和代碼生成的客戶端代理可以解決這些問題，因爲它們生成的客戶端想要理解「整個模式」而不是他們感興趣的位。另一種方法是讓他們使用Xml解析器，只是拔出他們需要的位。
如果您的Web服務正在開發或不斷變化那麼SOAP是真的不您最好的選擇，因爲它會與每一個變化，他們將不得不重新生成，重建和重新部署其服務客戶的意思。根據您的情況，您可能需要考慮提供REST + POX（Plain Old Xml）Web服務，因爲它更簡單，因爲它沒有SOAP開銷，可以通過普通URL調用，沒有（直接在瀏覽器例如，使用AJAX）一個的SOAPClient庫
我必須不同意以上所述，因爲我從來沒有使用PHP的SOAPClient，C＃（Mono/.NET）或Perl SOAP庫或使用JavaScript的請求/響應中的其他元素的問題（我會注意到至少有一個漂亮的JavaScript中的跨瀏覽器SOAP客戶端）。面向公共接口的REST選項對於混搭而言是很有價值的工具，但SOAP對於Web服務來說是一種更好的編程方法。 – 2010-02-09 10:45:19
Lain，如果您使用的是SOAP客戶端，那麼您不使用WSDL生成的代碼，那麼您所做的全部工作就是使用智能Xml解析器跳過SOAP頭以獲取有效內容（當然，您不會得到解析器錯誤與動態語言）。如果是這種情況，那麼SOAP Web服務的額外性能開銷和複雜性究竟有哪些好處？ – mythz 2010-02-09 18:38:23
由於SOAP客戶端使用WSDL生成的代碼，因此您的前提無效，當存在無關元素時，它們不會傾向於拋出錯誤。他們在實踐中幾乎都是這樣工作的。這決不會否定使用SOAP的優點，因爲鍋爐板應該全部自動化。因此，我會反擊非常容易實現（除非使用像RPC/Encoded格式那樣可怕並且不推薦的東西，這使SOAP在複雜性方面名聲不好）。 – 2010-02-12 15:25:59
一個可能的答案是使用替換組，使抽象的模型在XSD的導入。 處理這樣的替換組的可能性仍然需要用您用來調用這些服務的框架來驗證。
我建議有可能在客戶端捏造，並沒有使用SOAP接口，也許解析由一些可怕的手動解析/正則表達式軟糖的反應（這是驚人的，有多少人做到這一點）。我說這是因爲我經常在Unix和Windows系統上（用於Web應用程序，服務器端和桌面客戶端應用程序）在C＃，PHP，Perl和JavaScript中創建構建客戶端和服務器SOAP接口，並且從未遇到過這個問題（添加可選字段在請求或響應中從未造成過任何問題）。我會問他們使用什麼SOAP客戶端。 :-) – 2010-02-09 10:39:00