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。

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

无论如何，您确实需要“大”解决方案(出现了许多新的复杂问题)，而且您希望生产中只有一个具有其一个端点的服务，这样可以更好地将这两个变体作为不同的操作提供。这样您的API就会改变，但是所有的旧操作仍然可用。

假设(我只是不能测试它)：客户端应该不需要重新生成存根，因为他以前使用的存根没有改变。

因此，总的来说，我看到了这两种向后可重构的可能性：

• 将服务部署/运行多次(例如，多个端点，如/myServiceV1、/myServiceV2)。每个API更改的新版本/发行版
• 让服务部署/运行一次，但所有旧请求都保持不变。

希望这对做出决定有所帮助;)

Answer 2

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