Rest 如何在不破坏现有集成的情况下引入webhook负载的变化

在我们的应用程序资源（如用户/订单/装运）中发生特定事件时，我们将向订阅者通知事件发生情况以及事件的高级详细信息。对应用程序资源（如用户/订单/装运）的更改可以通过RESTWebAPI执行

现在由于业务需求，现有的webhook有效负载结构需要更改，引入该更改将打破现有的集成。在不破坏任何现有集成的情况下引入webhook负载更改的任何解决方案

现有webhook负载示例

{
  orderid : 123455,
  customerid : abc@domain.com,
  other properties ....
}

{
  orderid : 123455,
  customerid : 5435gd98, //modification
  other properties ....
}

未来webhook负载示例

{
  orderid : 123455,
  customerid : abc@domain.com,
  other properties ....
}

{
  orderid : 123455,
  customerid : 5435gd98, //modification
  other properties ....
}

---

理想情况下，在设计事件模式期间，您的事件中应该有一个

version

属性，该属性表示模式版本，如下所示。每当订阅者挂接到您的事件时，他们都会绑定到特定的版本，直到他们需要切换到新的版本。这样，每次转换到新模式时，都会在一定的宽限期内继续维护新旧模式，以实现向后兼容性，从而允许现有订阅服务器在不中断的情况下进行更新

{
  version : 1,
  orderid : 123455,
  customerid : abc@domain.com,
  other properties ....
}

{
  version : 2,
  orderid : 123455,
  customerid : 5435gd98, //modification
  other properties ....
}

但在现有的事件模式（没有版本控制）中，您似乎错过了这一培训。所以现在你至少需要一段时间来解决这个问题。但引入版本控制永远不会太迟。首先，您的活动如下所示。注意：我引入了

version

属性，以便从现在起任何新订阅者都知道这一点，而您现有的订阅者不会同时中断，因为现有的事件属性没有更改。同时，您可以通知那些旧订户转换到新订户。将来，这样的更改会更容易，因为现在您有了版本控制

{
  version : 2,
  orderid : 123455,
  customerid : abc@domain.com, // for V1 compatibility
  // name new customerid field something different, below is just for example
  customerid_v2 : 5435gd98, // V2
  other properties ....
}

或者可以是（在嵌套的json中移动客户详细信息）：

---

这很有道理。谢谢