JSON事件驱动与RESTful API比较

我很确定事件驱动已经是一个大问题，并且会变得更大。事实上，事件是JSON blob，并且通常我们希望它们在计算机程序中更容易使用。我以前也写过关于很难指定JSON格式化文章，也有关于无模式的消息处理。事实证明，JSON Schema世界虽然有好消息，但问题远未解决。

据我所知，实际上只有两种方法可以将软件连接在一起：API调用（我发送请求并等待您的响应）和事件（我触发了一条消息，无论是谁，它都可以执行任何操作做）。后者的一个常见变体是，与事件一起，你发送一个回调地址，可能希望活动消费者给你回调。

API很简单，对 程序员 来说很自然，因为我们都在成长，调用子程序和函数。有时候这种思维方式在网络上运行得很好，就像我向你发送一个HTTP请求，其中包含你需要为我做一些事情的所有事情，我等待回复说你做了什么。但是API存在问题，最糟糕的是它们构成紧密耦合; 你和我必须保持同步，如果有时我发出请求的速度比你能处理的如果要快一点，那么就糟糕了。

事件使耦合更加松散。显然，它留下了插入缓冲的自然位置; 如果我领先于你，那没关系，消息可以在传输过程中得到缓冲，最终当我放慢速度时你会赶上来，这很好。

更宽的松耦合留下空间来处理传输中的大量其他有用的东西：导出，记录/审计，转换，分析和过滤，仅举几例。我认为所有集成任务的很大一部分自然适合事件驱动的代码，而不是API。所以，我关心的是让它变得简单。

合同和模式 ·API通常具有自己合同和模式。在强类型编程语言中，它们是详细而严格的，在编译时进行验证，以便在运行时快速，可信地执行。对于RESTful API中，我们有类似的事情如/OpenAPI的，GraphQL 提供了另一种方法。

在面向事件的系统中的合同则完全不同，但有它们总比没有好。我听说有人写这种软件要求“模式”，我认为他们其实真正想要的是：

他们希望将消息自动神奇地转换为对象或接口或结构，或者用于编程语言的正确习惯。如果不能做到这一点，他们会希望他们尝试通过有用的诊断输出确定性地失败。

对于任何指定的消息类型，他们希望能够生成样本，以支持测试。

他们喜欢在事件架构中智能处理版本控制。

从历史上看，这很难。一个原因是我经常在事件中看到的：“EventType”字段。通常，事件流包含许多不同类型的事物，并且它们是自我描述的，因为每个事件都包含一个字段来说明它是什么。因此，如果没有基于该类型字段的调度，您无法真正解析它才能使其对程序员有用。更糟糕的是：我知道几个例子，你在顶级对象里有一个EventType枚举，然后在更深的嵌套级别进一步输入指定一个类型，每个EDA软件中事件都有EventType或类似事情。

特别是，由于事件往往是JSON blob，这是一个问题，因为从历史上看，JSON Schema 对这种构造的支持非常弱。您可以根据特定领域的进行调度解析，你可以排序，等等预先处理，降低消息处理的复杂性和错误消息。

但是，也有好消息。显然JSON Schema项目非常活跃，在当前的草案中（-07，因为我写这个），有一个if-then-else 结构。

banq注: 本文亮点是比较了JSON格式的同步和异步方式，如果希望将事件纳入JSON数据格式定义，这样搞下去，json会不会成为另外一个XML，有自己的schema，也就是XSD文件？