DevOps和持续交付并不强制应该怎么做事情，所以最有效率的方法更令人中意。

在我们的例子里，可以说把变更的实现分摊到生产者和消费者里是代价最小的办法。

不管怎样，生产者需要变化，而消费者需要接受实现Tolerant Reader的一次性开销。通过SOAP和XIVIL来实现也是可以的，但是相比REST来说显得不那么自然。这也是为什么在拥抱DevOps和持续交付的企业里，REST的实现更加流行的一个原因。

如何实现Tolerant Reader模式在实践中因平台而异。对JsonRest来说，通常把JSON结构转换成同等的语言结构就足够了。你的程序需要哪些部分，你就用哪些部分。所有的其他部分，不管是旧的还是新的，通通忽略掉。这种办法的局限是，生产者不能移除消费者依赖的部分。增加新部分没有问题，因为它们将会被忽略。

这样又给生产者增加了负担，它必须记住哪些是消费者需要的。

在企业的高墙内，这并不是什么大问题。生产者可以知道消费者最新的代码并在构建生产者的阶段进行测试。

而对于那些暴露在因特网上的服务，这种方法并不那么实用，这时会倾向于使用更为严格的SOAP方式。