DevOps和持續交付并不強制應該怎么做事情，所以最有效率的方法更令人中意。

在我們的例子里，可以說把變更的實現分攤到生產者和消費者里是代價最小的辦法。

不管怎樣，生產者需要變化，而消費者需要接受實現Tolerant Reader的一次性開銷。通過SOAP和XIVIL來實現也是可以的，但是相比REST來說顯得不那么自然。這也是為什么在擁抱DevOps和持續交付的企業里，REST的實現更加流行的一個原因。

如何實現Tolerant Reader模式在實踐中因平臺而異。對JsonRest來說，通常把JSON結構轉換成同等的語言結構就足夠了。你的程序需要哪些部分，你就用哪些部分。所有的其他部分，不管是舊的還是新的，通通忽略掉。這種辦法的局限是，生產者不能移除消費者依賴的部分。增加新部分沒有問題，因為它們將會被忽略。

這樣又給生產者增加了負擔，它必須記住哪些是消費者需要的。

在企業的高墻內，這并不是什么大問題。生產者可以知道消費者最新的代碼并在構建生產者的階段進行測試。

而對于那些暴露在因特網上的服務，這種方法并不那么實用，這時會傾向于使用更為嚴格的SOAP方式。