java - Web服务向后兼容性

Question

我有一个网络服务，它将一个 ID 作为输入，返回与该 ID 关联的对象。

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

我在这里担心的是，在合并新更改的同时，我想保持向后兼容性。关于输入，我已经通过在同一字段中接受“，”分隔字符串来解决问题。因此无需担心与输入的向后兼容性。

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

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

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

Answer 1

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

我工作过的大公司(如 1k IT 主管及以上)过去常常对他们的 WSDL/XSD 进行版本控制。对 WSDL/XSD 的任何结构更改都将作为服务本身的新版本受到威胁，因此结构更改需要正式发布服务以填充其新的 WSDL/XSD 和相应的变更日志。

两家公司随后在不同端点下部署了组件的新版本和旧版本(例如 wsdl/xsd)，旧版本的生命周期结束大约 6-12 个月，以保证向后兼容性.

这样一来，当前的客户无需进行任何更改，我们的 B2B 合作伙伴就可以开始实现新的 API。

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

无论您确实需要那个“大”解决方案(复杂性会带来许多新麻烦)，并且您希望在生产环境中只拥有 1 个服务及其 1 个端点，这可能会更好地提供两种变体作为不同的操作。这样，您的 API 发生了变化，但所有旧操作仍然可用。

假设(我只是无法测试它):客户不需要重新生成 stub ，因为他曾经使用过的东西没有改变。

所以基本上我看到了一般获得向后兼容性的两种可能性:

• 多次部署/运行服务(例如，多个端点，如/myServiceV1、/myServiceV2)。每个 API 更改一个新版本/发布

• 已部署/运行服务一次，但所有旧请求均未更改，成为该服务的一部分。

希望对您的决定有所帮助 ;)