Webservice向后兼容性

Question

我有一个Web服务，它将id作为输入返回与该id相关联的对象。

现在我要求此Web服务接受多个id并返回与这些id相关联的多个对象。

我担心的是，在整合新的更改时，我希望保持向后兼容性。关于输入，我通过在同一字段中接受“，”分隔的字符串来解决问题。所以不要担心向后兼容输入。

但是对于输出，它将是一个对象列表而不是一个对象。

所以我的问题是将返回对象列表而不是单个对象中断向后兼容性。我知道客户端必须更改接受服务结果接受列表的那段代码。

什么是行业标准。这种变化是否被视为破坏向后兼容性。

Answer 1

首先：是的，这是API的更改，它不向后兼容（例如，客户需要更改某些内容，因为响应的结构已从单个元素更改为元素列表）。

我曾经工作过的大公司（比如1k IT主管及以上）已经使用了WSDL / XSD版本。然后，对WSDL / XSD的任何结构更改都将作为服务本身的新版本进行威胁，因此结构更改需要正式发布服务以填充其新的WSDL / XSD和相应的更改日志。

两家公司随后在不同的端点下部署了新版本以及旧版本的组件（例如wsdl / xsd），旧版本的活动结束时间约为6-12个月，以保证向后兼容性。

通过这种方式，当前客户无需进行任何更改，我们的B2B合作伙伴可以开始实施新API。

因此，在您的情况下，您可以通过以类似方式使用两个版本来提供向后兼容性。我想这可以被看作是一个生活的行业标准。

无论你真的需要那个“大”的解决方案（有很多新的复杂问题）而且你希望在生产中只有一个服务，其中1个端点可以更好地提供两种变体作为不同的操作。这样您的API会发生变化，但所有旧操作仍然可用。

Assumptation（我无法测试它）：客户端不应该重新生成存根，因为他以前使用的onces没有改变。

所以我基本上看到了这两种可能性，以便在一般情况下实现倒退：

• 多次部署/运行服务（例如/ myServiceV1，/ myServiceV2等多个端点）。每个API更改的新版本/版本

• 让服务部署/运行一次，但保持该服务的所有旧请求不变。

希望有所帮助做出决定;）

Answer 2

如果客户端必须修改ANYTHING，则它不向后兼容。但是，我不明白为什么你需要更改当前存在的端口/端点。而是将另一个添加到服务中。使用现有端口/端点的任何客户端都不需要更改任何内容。