在Web API和消息流之间进行选择电视电影小迷妹 TVco.cn

当面对各种各样的选择时，开发人员如何构建API应该知道哪种是正确的解决方案？在本文中，我将概述REST API和消息流的共同特征，以便开发人员可以更好地了解何时（以及何时不使用）每一种。

基于REST的Web API的特征-

基于REST的Web API在客户端（API使用者）和API服务器（后端）之间创建对话。当我们在Capital One中构建基于REST的API时，我们使用HTTP作为协议。我们的设计在很大程度上依赖于HTTP，从方法（例如GET，POST，PUT，PATCH，DELETE）到可帮助我们在客户端和服务器之间进行通信的标头（例如授权，接受，内容类型）。

 
  GET /项目 
  接受：application / json

  200 OK 
  内容类型：application / json 

  [ 
  {“ Id”：“…”，“ name”：“…”}， 
  {“ Id”：“…”，“ name”：“…”}， 
  {“ Id”：“…”，“ name”：“…”}， 
  … 
  ]

  POST /项目 
  内容类型：application / json 
  { “名称”：”…”， … }

  创建了201 
  内容类型：application / json 

  {“ Id”：“…”，“ name”：“…”，...}

客户端（或API使用者）是应用程序，它在需要时向API发送消息（即HTTP请求）。然后，服务器用响应进行响应，包括指示请求是否已成功处理的状态码（2xx错误代码），由于客户端错误而失败（4xx错误代码）或由于服务器错误而失败（5xx错误代码）。所有通信都从使用者流向API后端。

当我们添加超媒体链接时，我们使用一些可能对客户端有用的附加信息来扩展对话：

  GET / projects / 12345 
  接受：application / json

  200 OK 
  内容类型：application / json 

  { 
  “名称”：”…”， …， 
  “ _links”：{ 
  {“ self”：” / projects / 1234”}， 
  {“ related_projects”：[ 
  {“ 4567”：” / projects / 4567”}， 
  {“ 8901”：” / projects / 8901”}， 
  {“ 9012”：” / projects / 9012”} 
  ] 
  }， 
  {“成员”：[ 
  {“ 1”：” / users / 1”}， 
  {“ 2”：” / users / 2”}， 
  {“ 3”：” / users / 3”}， 
  {“ 4”：” / users / 4”}， 
  {“ 5”：” / users / 5”} 
  ] 
  } 
  }

基于REST的API具有一组特定的特征，总结如下：

请求/响应模型 -API使用者将请求发送到API服务器并接收响应。
基于拉式的交互 -API使用者在需要数据或功能时（例如，用户界面，在预定的时间）发送API请求。
同步 -API使用者在发送请求后收到响应。
多种内容类型 -由于REST API建立在HTTP之上，因此响应可以是JSON，XML或其他满足消费者需求的内容类型（例如CSV，PDF）。
灵活的交互 -基于可用的HTTP动词，使用者可以通过多种方式通过资源与基于REST的API进行交互：查询/搜索，创建新资源，修改现有资源以及删除资源。我们还可以通过将这些交互组合到更高级别的流程中来构建复杂的工作流。
缓存和并发协议支持 -HTTP具有内置的缓存语义，允许将缓存服务器放置在使用者服务器和API服务器之间，还可以对响应和eTag进行缓存控制以进行并发控制以防止覆盖内容。
内部和外部访问 -REST API可能仅限内部使用，或者由合作伙伴或公共开发人员外部使用。

对于大多数解决方案，提供基于REST的API是一个很好的起点，它允许任何应用程序或自动化脚本通过HTTP与您的API交互。

消息流的特征

与REST API不同，消息流更好地在新消息到达时提供通知。订阅后，将在有新消息可用时通知客户端：

  POST /项目 
  内容类型：application / json 
  { “名称”：”…”， … }

  创建了201 
  内容类型：application / json

现在，客户端已订阅主题，当有新消息可用时，它将接收通知。这可能是REST API处理来自Web或移动应用程序的传入请求，然后将消息添加到消息流主题中以通知感兴趣的任何人的结果：

  <<将消息发布到project_messages：

  项目创建>>

  <<将消息发布到project_messages：

  项目存档>>

  <<将消息发布到project_messages：

  项目更新>>

  <<通知client1234：

  3条新讯息>>

注意我们的对话如何变得更加有趣。现在，当事情发生变化或发生重大业务事件时，我们可以得到通知；无需修改和重新部署API即可支持将来出现的新集成。这称为“ 松散耦合” ，它可以帮助我们的系统以新方式使用，而消息的始发者甚至无需了解当前和将来的订户。

那些熟悉消息代理的人会意识到这很熟悉。消息代理与消息流之间的区别在于， 消息流还使我们能够按顺序重新访问过去的消息 ：

<>

<>

当我们需要汇总值或执行以前没有意识到的新计算时，此功能很有用。

注意-请求消息时，我们无法过滤消息或执行其他汇总查询-只有客户端从主题请求消息后才能执行此操作。 REST API比消息流更适合执行临时查询。

正如您所发现的，消息流是与基于REST的API不同的交互方式。消息流的其他特征总结如下：

发布/订阅模型 -应用程序或API将消息发布到可能具有零个，一个或多个订阅者的主题，而不是请求/响应模型。
订阅者通知交互 -应用在新消息可用时（例如，数据被修改或新数据可用时）接收通知。
异步 -与REST API不同，应用程序不能使用消息流来提交请求和接收回响应，而无需各方之间的复杂协调。
单一内容类型 -在Capital One，我们的消息流基于Avro构建，Avro是一种紧凑的二进制格式，可用于数据序列化。与HTTP不同，Avro不支持其他内容类型（例如CSV，PDF）。
可重播性-在Capital One，我们的消息流基于Kafka构建，订阅者可以按顺序重访和重播以前的消息。
不支持缓存或并发协议 —消息流不提供发布者和订阅者之间的缓存语义，缓存控制或并发控制。
仅内部访问 -与HTTP不同的是，订户必须在组织内部，而HTTP可能被外部化为合作伙伴或公共消费者。

消息流提供了一些其他通信选项，这些通信选项不是基于REST的API所没有的-当发生新数据或状态更改时基于推送的通知，以及重新访问流中的过去消息以执行新计算或重新执行以前失败的逻辑的选项。当结合在一起时，REST-API使使用中的应用程序可以轻松地与HTTP API集成，同时消息流允许消费者通知更改，而无需先与REST API进行核对。这可能是一个强大的组合，可以满足当前存在的用例，同时允许将来处理新兴用例-所有这些都无需修改现有系统以适应新解决方案。

摘要

您可能已经意识到，只要了解每种API的特性，就可以在Web API和消息流之间进行选择并不困难。 REST API最适合于客户端应用程序通过HTTP向API后端发送请求的请求/响应交互。消息流最适合在发生新数据或事件时通知您，您可能要对其采取措施。只要确保使用一种或多种方法来满足消费者的需求，即可为您的解决方案功能提供可靠的接口。