情况如下：
不同地点的两个团队正在开发同一个产品，但是我们无法访问彼此的资源。一个团队 - 后端（应用服务器），另一个团队 - GUI（客户端）。
服务器请求/响应变化非常频繁，第二个团队（客户端）知道在这个过程中为时已晚，通过理智，
我们的目标是：尽早发现问题或双方的任何变化，甚至在它引发错误之前。
我的想法：应用服务器支持并由 UI 使用的所有 json 响应/请求都将转换为 xsd（基于 json 与 xml 非常等效的事实），然后我们将有一个 xsd： 1. 服务器侧将维护每个构建并使其可访问 2. 客户端将验证自身（即使在每晚的测试基础上）
第二个想法： Apps erver 将有一个集成测试（我们以任何方式拥有它们），它将验证带有一些 json 内容的请求/响应格式，比如说存储在文件系统上，作为下一步，测试将检查 json 格式是否是与之前的测试运行不同。每晚运行这些集成测试，并在检测到违反合同后向其他团队发送邮件。
跟踪这些持续变化的任何其他好主意？
谢谢伊戈尔
看看 JSON 模式： http: //json-schema.org/ 我个人还没有尝试过，但似乎这正是你所需要的。
您正在描述一个经典问题，即管理对不受您直接控制的系统使用的已发布界面的更改。
您最初的两个想法都在正确的轨道上：第一个是您的服务器团队就更改进行交流的一种方式，这样您的客户端团队就有一种明显的方式来查看发生了什么变化。第二种方法是捕获通信失败的情况，以便在错误成为生产问题之前检测到错误。
我认为诀窍在于获得正确的细节，以便正确的人在正确的时间听到这些变化。为此，在您的第一个基础上，这里有一些额外的想法：
让集成测试作为客户端和服务器团队之间的共同努力来维护。然后，客户端团队可以编写测试来验证他们的代码所做出的期望，然后服务器团队可以在发布任何更改之前在非生产环境中运行这些测试。这假设只有一个客户端团队：如果您正在处理许多第三方使用的公共 API，那么您可能别无选择，只能让服务器团队简单地猜测客户端的需求是什么；这不太理想，但如果您的 API 非常简单并且没有太多用例需要考虑，它仍然可以工作。
让客户团队及早知道重大变更何时到来，以便他们准备好以冷静和轻松的方式解决它，而不是疯狂地争先恐后地解决生产问题。如果您编写的工具能够查看模式的两个版本并在发布代码供客户团队处理之前发现任何重大更改，那么您生成的模式可以帮助您解决这个问题。
与客户团队就什么被认为是重大更改以及他们的客户代码应该是健壮的内容达成一致。例如，您可能同意，向现有对象添加新属性不是重大更改，客户端代码必须简单地忽略它，但这需要服务器开发人员遵守纪律，永远不要添加新属性改变另一个现有的解释。一旦您就重大更改的构成达成一致，客户端开发人员可以围绕这些假设构建他们的代码，服务器开发人员可以注意到被认为是重大更改的更改并将它们标记为早期沟通。
实施机制以对某些类型的更改启用多步骤弃用周期。例如，如果您经常重命名属性，您可以在服务器端代码中构建一个功能，允许您声明一个对象属性是另一个对象的别名。让服务器代码立即在 JSON 有效负载中包含所有可能的属性名称，以便客户端无论期望使用哪个名称都可以工作。然后，您可以告诉客户端开发人员别名将在给定时间段内保留，之后他们应该更改代码以使用新名称，您可以删除别名。一个相关的策略是从你的模式中自动生成一个简单的客户端库，并让客户端团队使用它，而不是直接访问 API；
我已应用上述所有策略来管理对我维护的 Web 服务 API 的更改。每种情况都不同，但希望这些想法能给您一些想法，让您了解如何在您的环境中实现类似的效果。