如果您的意图只是向新消费者提供新的功能,并且所有消费者都是直接的消费者(无中介机构,框架等),则离散的端点方法是最佳选择.每次添加一个可能会中断的功能时,请创建一个新的端点,给它一个新的版本号,然后让消费者知道验证它并切换其配置.这个策略是相当尝试和真实的,但它的缺点是使消费者的负担保持最新.此外,如果服务之间有依赖关系,那么它可能会成为追踪的烦恼.如果代码破坏它不是(直接)你的错

另一个主要的策略是可扩展的接口.这里有三种不同的品种,我知道.首先,是尝试如此良好地描述服务域的接口类型,每个可能添加的功能都可能在给定现有接口的情况下可能.如果听起来很难,那就是.你可以称之为完美的界面.一切都是完全描述的,但整个领域也是完全描述的. “完美”只是在纸上.

第二种是类似普通接口的类型,但添加通用扩展点.在WSDL中,这意味着xs：any,name-value对或类似的东西.你可以称之为基本的可扩展接口.这不是太难做,但并不是没有复杂化.扩展点可能会使界面更难以在某些工具(xs：any)中使用,或明确地失去一些验证输入和输出(名称 – 值对)的能力.很容易滥用这些扩展点,使得版本3或4很难使用.

第三种是将您的界面转换为字节流的类型.你可以称这些神界面.他们不是没有理由,但是如果你使用它们,你可能想问一下为什么你使用的是Web服务.也许你应该考虑原始TCP / IP或基本的HTTP GET / POST.但是,也许您已经厌倦了WSDL和XSD的复杂性,您只想从头开始,但是由于某些基础设施原因,您被绑定到Web服务.然而,实现一旦你开始这个路径,你将需要一个全新的方式来描述给你的消费者如何/不使用你的服务,如果你使用XSD,那么你基本上是在哪里你开始了

您最好的办法是先了解所有这些选项,并通过首先尝试“完美的界面”来接近您的服务设计,然后放弃并添加通用的可扩展性点.尝试设计完美的界面将迫使您学习将使您的服务更好的东西,而不仅仅是您的界面,但需要时间,如果您不以某种方式限制时间,它将永远存在.

有一点点真正的神界面,有包装界面.如果你的系统有层,你希望你的界面也是层层的.当您更改B层时,您只想更改层B,而不是层C中的所有实例.