如何在不破坏现有集成的情况下引入 webhook 有效负载的更改

Question

在我们的应用程序资源（如 user/order/shipment ）中发生某些事件时，我们会通过事件的高级详细信息通知订阅者有关事件的发生。可以通过 REST Web api 执行对用户/订单/发货等应用程序资源的更改。

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

现有 webhook 负载示例

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

Future webhook 有效负载示例

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

Answer 1

理想情况下，在设计事件架构期间，您的事件中应该有一个 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 中移动客户详细信息）：

{
  version : 2,
  orderid : 123455,
  customerid : abc@domain.com, // for V1 compatibility
  customer : { 
    id : 5435gd98,
    email : abc@domain.com
  }
  other properties ....
}