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

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

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

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

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

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

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