TolerantReader

使用Web服務的好處之一是它可以幫助您分離系統的各個部分。人們可以在不同的代碼基礎上進行一定程度的分離。盡管你得到了一些解耦，但你不能完全消除耦合，因為服務仍然需要通過它們的接口相互通信。可悲的是，許多團隊使這種耦合比應該更糟糕。

解耦合作的治理法律應該是Postel定律：

在你所做的事情上要保守，在你接受別人的事情時要自由。

- 喬恩Postel

在合作服務的情況下，最棘手的問題之一就是進化。雖然有些人認為你應該第一次正確地定義你的服務定義，所以你永遠不需要改變他們，但是我的經常讀者不會驚訝地發現我離開他們的派對。為了能夠發展服務，您需要確保提供商可以進行更改以支持新需求，同時最大限度地減少對其現有客戶的破壞。

自從撰寫這份bliki條目以來，Rob Daigneau在服務設計模式中發布了這種模式的完整描述

填補這個問題的常見方法是使用某種模式驅動的服務端點綁定。一個例子是從XSD定義中生成代碼的C＃類。這被視為一種節省時間的功能 - 服務提供商發布其服務的XSD定義，消費者獲取副本並生成一個類。看，可以不編程。它運行良好，直到提供者需要對接口進行任何更改，例如添加字段。將字段添加到像這樣的界面不應該是任何人的重大改變 - 但通常會打破這些方案。

我的建議是在從服務中讀取數據時盡可能寬容。如果你使用的是XML文件，那麽只需要你需要的元素，忽略任何你不需要的元素。此外，對您正在使用的XML的結構做出最小假設。

最重要的是，確保只有一點代碼能夠讀取像這樣的數據有效載荷。數據傳輸對象的目的之一是將數據有效載荷包裝在方便對象的後面，這樣系統的其余部分就可以走到anOrderHistory.orders 並且不受變化的影響，甚至會破壞容錯讀者。

即使您的數據傳輸協議是二進制文件，也應該牢記這一原則。假設您在連接的兩端都有java程序，並且想要使用二進制傳輸來保持消息的大小。

為了幫助服務提供商發展他們的服務，您可以傳達您正在閱讀的通信的哪些部分。這樣做的好方法是給讀者和測試者發送它們，以便他們可以在構建過程中使用它們來檢測潛在的破壞。有些人可能會認為這是消費者驅動合同的下一步

進一步閱讀

服務設計模式中有這種模式的完整描述。

幾年前，我的同事Ian Cartwright發布了一系列有用的博客文章。他指出，模式驗證提供了一種錯誤的安全感，並且在序列化中存在一些危險，無論是通用還是特定的域對象。

Saleem Siddiqui描述了一個寬容的讀者如何與一個善良的作家合作。

容錯性讀取器