为什么我应该优先选择基于HTTP RPC JSON-Messaging样式的HTTP REST和CQRS?

Roo*_*ian 5 rest rpc json cqrs

每当我读到Web服务应该如何通信时,首先出现的是:

使用REST,因为它将客户端和服务器分离!

我想建立一个Web服务,每个QueryCommand是一个HTTP-端点.使用REST,我会有更少的端点,因为它考虑资源而不是操作的性质(通常比资源有更多的操作).

  • 为什么使用RPC over REST有更强的耦合?
  • 使用REST而非RPC Json-Messaging样式有什么好处?

附加信息:使用消息传递我的意思是同步消息(请求/响应)

更新:我认为只有一个Http端点可以处理QueryCommand取决于给定的Http动词也是可能/更好的.

Mar*_*ann 6

在我进入CQRS部分之前,我想花点时间谈谈REST的优缺点.在我们就何时以及为何使用REST建立共识之前,我认为不可能回答这个问题.

休息

与大多数其他技术选项一样,REST也不是灵丹妙药.它有优点和缺点.

我喜欢使用Richardson的成熟度模型,将Martin Fowler的额外0级作为一种思维工具.

0级

Martin Fowler也将POX的沼泽称为0级,但我认为真正区分这个级别的只是使用RPC over HTTP.它不一定是XML; 它可能是JSON而不是.

这一级别的主要优势是互操作性.大多数系统可以通过HTTP进行通信,大多数编程平台都可以处理XML或JSON.

缺点是,系统难以独立发展的客户(见第3级).

这种风格的一个显着特征是所有通信都通过一个端点.

1级

在级别1,您开始将API的各个部分视为单独的资源.每个资源都由URL标识.

一个优点是您现在可以开始使用现成的软件(例如防火墙和代理服务器)来控制对系统各个不同部分的访问.您也可以使用HTTP重定向将客户端指向不同的端点,尽管在这方面存在一些缺陷.

除了0级之外,我想不出任何缺点.

2级

在这个层面上,不仅你有资源,但你也可以使用HTTP动词,如GET,POST,DELETE,等.

一个优点是您现在可以开始更多地利用HTTP基础结构.例如,您可以指示客户端缓存对GET请求的响应,而其他请求通常不可缓存.同样,您可以使用标准HTTP防火墙和代理来实现缓存.您可以免费获得"网络规模"缓存.

级别2构建在级别1上的原因是您需要将每个资源分开,因为您希望能够彼此独立地缓存资源.如果您无法区分各种资源,或者无法区分读取和写入,则无法执行此操作.

缺点是,它可能涉及更多的编程工作来实现这一点.此外,所有先前的缺点仍然适用.客户端与您发布的API紧密耦合.如果您更改了URL结构,则客户端会中断.如果更改数据格式,客户端会中断.

尽管如此,许多所谓的REST API都是在这个级别设计和发布的,所以在实践中似乎很多组织都认为这是优点和缺点之间的良好平衡.

3级

这是REST设计的级别,我认为是真正的REST.它与以前的水平完全不同; 这是设计API的完全不同的方式.在我看来,0-2级和3级之间存在严重分歧.

第3级的一个显着特征是必须将内容协商视为API设计.但是,一旦你有了这个,那么选择这种API设计风格的理由就会变得更加清晰.

对我而言,3级API 的主要优势在于您可以独立于客户进化它们.如果您小心,可以在不破坏现有客户端的情况下更改API的结构,甚至导航图.如果您需要引入重大更改,您可以使用内容协商来确保客户端可以选择进行重大更改,而旧版客户端将继续工作.

基本上,当我被要求编写一个我无法控制客户端的API时,我的默认选择是3级.

设计一个3级REST API需要你以一种与众不同的方式进行设计,这是一个缺点.另一个缺点是客户端开发人员经常发现这种API设计风格不熟悉,因此他们经常尝试对您的URL结构进行二次猜测或重新设计.如果他们这样做,你将不得不花费一些努力来阻止他们这样做,因为这将阻止你进化API.

换句话说,3级API需要大量的开发工作,特别是在服务器端,但客户端也变得更加复杂.

但是,我将重申优势:您可以独立于客户端发展3级REST API.如果您不控制客户端,则向后兼容性至关重要.级别3使您可以在保持兼容性的同时发展API.我不知道你可以用任何其他风格来实现这一点.

CQRS

现在我们已经确定了REST的一些优点和缺点,我们可以开始讨论它是否适用于CQRS.

Greg Young与Udi Dahan就CQRS达成的最基本协议是,它不是顶级架构.

简而言之,其原因在于构成CQRS系统的消息(命令和事件)和查询对解释很敏感.为了什么,客户端必须知道哪些命令发出,服务器必须知道如何解释它.因此,该命令是系统的一部分.

系统可以跨客户端和服务器分布,但是消息和数据结构彼此耦合.如果您更改服务器解释给定邮件的方式,则该更改将影响您的客户.您无法在CQRS架构中独立地发展客户端和服务器,这也是它不是顶级架构的原因.

因此,鉴于它不是顶级架构,传输架构变得相当无关紧要.从某种意义上说,发送消息所需的唯一内容是单个"服务总线"端点,如果您只需要互操作性,则可以很容易地成为0级端点.毕竟,你唯一要做的就是在队列中放一条消息.

那么,最终的答案是,一如既往:它取决于.

交货速度是最重要的标准吗?您可以同时控制所有客户端和服务器吗?那么,也许你只需要0级.也许2级很好.

另一方面,如果您的客户无法控制(移动应用程序,硬件(IoT),使用您的公共API的业务合作伙伴等),您必须考虑如何处理向后兼容性,在这种情况下,级别3是(IMO)需要的.但是,在这种情况下,我建议保留CQRS的实现细节.