DevOps和持续交付并不强制应该怎么做事情,所以最有效率的方法更令人中意。
在我们的例子里,可以说把变更的实现分摊到生产者和消费者里是代价最小的办法。
不管怎样,生产者需要变化,而消费者需要接受实现Tolerant Reader的一次性开销。通过SOAP和XIVIL来实现也是可以的,但是相比REST来说显得不那么自然。这也是为什么在拥抱DevOps和持续交付的企业里,REST的实现更加流行的一个原因。
如何实现Tolerant Reader模式在实践中因平台而异。对JsonRest来说,通常把JSON结构转换成同等的语言结构就足够了。你的程序需要哪些部分,你就用哪些部分。所有的其他部分,不管是旧的还是新的,通通忽略掉。这种办法的局限是,生产者不能移除消费者依赖的部分。增加新部分没有问题,因为它们将会被忽略。
这样又给生产者增加了负担,它必须记住哪些是消费者需要的。
在企业的高墙内,这并不是什么大问题。生产者可以知道消费者最新的代码并在构建生产者的阶段进行测试。
而对于那些暴露在因特网上的服务,这种方法并不那么实用,这时会倾向于使用更为严格的SOAP方式。