PROSAGA码农传奇-SOA/RPC-为什么我应该优先选择基于HTTP RPC JSON-Messaging样式的HTTP REST和CQRS？

<div class =“post-text”itemprop =“text”>
  
    在我进入CQRS部分之前，我想花点时间谈谈REST的优缺点。在我们就何时以及为何使用REST建立共识之前，我认为不可能回答这个问题。
  
  <H1>
    休息
  </H1>
  
    与大多数其他技术选项一样，REST也不是灵丹妙药。它有优点和缺点。
  
  
    我喜欢用
    <a href="https://martinfowler.com/articles/richardsonMaturityModel.html" rel="noreferrer">
      Richardson的成熟度模型，Martin Fowler的额外等级0
    </A>
    ，作为一种思维工具。
  
  <H2>
    0级
  </H2>
  
    Martin Fowler也称0级
    
      POX的沼泽
    
    ，但我认为真正区分这个级别的只是使用RPC over HTTP。它不一定是XML;它可能是JSON而不是。
  
  
    首要的
    的
      优点
    </强>
     在这个层面上是互操作性。大多数系统可以通过HTTP进行通信，大多数编程平台都可以处理XML或JSON。
  
  
    该
    的
      坏处
    </强>
     系统很难独立于客户而发展（见第3级）。
  
  
    这种风格的一个显着特征是所有通信都通过一个端点。
  
  <H2>
    1级
  </H2>
  
    在级别1，您开始将API的各个部分视为单独的资源。每个资源都由URL标识。
  
  
    一
    的
      优点
    </强>
     现在，您可以开始使用现成的软件（如防火墙和代理服务器）来控制对系统各个不同部分的访问。您也可以使用HTTP重定向将客户端指向不同的端点，尽管在这方面存在一些缺陷。
  
  
    我什么都想不到
    的
      缺点
    </强>
    ，除了0级。
  
  <H2>
    2级
  </H2>
  
    在这个级别，您不仅拥有资源，还使用HTTP动词，例如
     <code>
 GET
 </code>
    ，
     <code>
 POST
 </code>
    ，
     <code>
 DELETE
 </code>
    等
  
  
    一
    的
      优点
    </强>
     是你现在可以开始更多地利用HTTP基础设施。例如，您可以指示客户端缓存响应
     <code>
 GET
 </code>
     请求，而其他请求通常不可缓存。同样，您可以使用标准HTTP防火墙和代理来实现缓存。您可以免费获得“网络规模”缓存。
  
  
    级别2构建在级别1上的原因是您需要将每个资源分开，因为您希望能够彼此独立地缓存资源。如果您无法区分各种资源，或者无法区分读取和写入，则无法执行此操作。
  
  
    该
    的
      坏处
    </强>
     这可能涉及更多的编程工作来实现这一点。此外，所有先前的缺点仍然适用。客户端与您发布的API紧密耦合。如果您更改了URL结构，则客户端会中断。如果更改数据格式，客户端会中断。
  
  
    尽管如此，许多所谓的REST API都是在这个级别设计和发布的，所以在实践中似乎很多组织都认为这是优点和缺点之间的良好平衡。
  
  <H2>
    3级
  </H2>
  
    这是REST设计的级别，我认为是真正的REST。它与以前的水平完全不同;这是设计API的完全不同的方式。在我看来，0-2级和3级之间存在严重分歧。
  
  
    3级的一个显着特征是
    <a href="http://blog.ploeh.dk/2015/06/22/rest-implies-content-negotiation" rel="noreferrer">
      您
      
        必须
      
       将内容协商纳入API设计
    </A>
    。但是，一旦你有了这个，那么选择这种API设计风格的理由就会变得更加清晰。
  
  
    对我来说，占主导地位
    的
      优点
    </强>
     3级API的一个原因是您可以独立于客户进化它们。如果您小心，可以在不破坏现有客户端的情况下更改API的结构，甚至导航图。如果您需要引入重大更改，您可以使用内容协商来确保客户端可以选择进行重大更改，而旧版客户端将继续工作。
  
  
    基本上，当我被要求编写一个我无法控制客户端的API时，我的默认选择是3级。
  
  
    设计3级REST API要求你以一种与众不同的方式进行设计，这就是a
    的
      坏处
    </强>
    。另一个缺点是客户端开发人员经常发现这种API设计风格不熟悉，所以
    <a href="http://blog.ploeh.dk/2013/05/01/rest-lesson-learned-avoid-hackable-urls" rel="noreferrer">
      他们经常尝试对您的网址结构进行二次猜测或重新设计
    </A>
    。如果他们这样做，你将不得不花费一些努力来阻止他们这样做，因为这将阻止你进化API。
  
  
    换句话说，3级API需要大量的开发工作，特别是在服务器端，但客户端也变得更加复杂。
  
  
    但是，我将重申优势：您可以独立于客户端发展3级REST API。如果您不控制客户端，则向后兼容性至关重要。级别3使您可以在保持兼容性的同时发展API。我不知道你可以用任何其他风格来实现这一点。
  
  <H1>
    CQRS
  </H1>
  
    现在我们已经确定了REST的一些优点和缺点，我们可以开始讨论它是否适用于CQRS。
  
  
    Greg Young和Udi Dahan就CQRS达成的最基本协议是
    <a href="http://udidahan.com/2012/02/10/udi-greg-reach-cqrs-agreement" rel="noreferrer">
      它不是顶级架构
    </A>
    。
  
  
    简而言之，其原因在于构成CQRS系统的消息（命令和事件）和查询对解释很敏感。为了
    
      做
    
     某些东西，客户端必须知道要发出哪个命令，服务器必须知道如何解释它。因此，该命令是系统的一部分。
  
  
    系统可以跨客户端和服务器分布，但是消息和数据结构彼此耦合。如果您更改服务器解释给定邮件的方式，则该更改将影响您的客户。您无法在CQRS架构中独立地发展客户端和服务器，这也是它不是顶级架构的原因。
  
  
    因此，鉴于它不是顶级架构，传输架构变得相当无关紧要。从某种意义上说，发送消息所需的唯一内容是单个“服务总线”端点，如果您只需要互操作性，则可以很容易地成为0级端点。毕竟，你唯一要做的就是在队列中放一条消息。
  
  
    那么，最后的答案是：
    的
      这取决于。
    </强>
  
  
    交货速度是最重要的标准吗？您可以同时控制所有客户端和服务器吗？那么，也许你只需要0级。也许2级很好。
  
  
    另一方面，如果您的客户无法控制（移动应用程序，硬件（IoT），使用您的公共API的业务合作伙伴等），
    
      必须
    
     考虑如何处理向后和向前兼容性，在这种情况下，级别3是（IMO）所需的。但是，在这种情况下，我建议保留CQRS的实现细节。
  
</DIV>