JSON事件驱动与RESTful API比较

banq 18-09-24
                   

我很确定事件驱动已经是一个大问题,并且会变得更大。事实上,事件是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文件? XML和区块链是怪胎