rest_REST /使用提要发布事件

最新推荐文章于 2022-06-22 17:15:16 发布

cunfen8879

最新推荐文章于 2022-06-22 17:15:16 发布

阅读量87

点赞数

文章标签： java python 数据库 mysql linux

原文链接：https://www.javacodegeeks.com/2020/05/rest-using-feeds-to-publish-events.html

版权

rest

处理事件

当使用多个解耦的服务时(例如，在微服务体系结构中)，很有可能需要一种将某种域事件从一个服务发布到一个或多个其他服务的方法。

许多广泛采用的解决方案依赖于单独的基础结构来解决此问题(例如事件总线或消息队列)。

活动提要

解决此问题的另一种方法是使用提要。 RSS或ATOM之类的提要通常用于订阅网页。每当将新文章发布到订阅的网页时，提要阅读器应用程序(例如，浏览器插件或移动应用程序)都可以将新文章通知用户。提要阅读器通常会定期轮询提供的提要端点，以查看是否有新文章。

可以使用提要将事件发布到其他服务，而不是将新文章发布到RSS阅读器。除了用于存储事件(您可能已经拥有)的标准数据库之外，这不需要任何其他基础结构。

RSS和ATOM都是XML格式，因此如果我们要提供JSON API，则不合适。还有JSON Feed ，类似于RSS和ATOM，但使用JSON。像RSS和ATOM一样，JSON Feed专注于网站内容，因此，许多(可选)提要和提要项属性对于发布域事件(例如favicon ， content_html ， image ， banner和附件)不是很有用。但是，JSON Feed具有简单的扩展机制，可让我们在Feed中定义自定义字段。这些字段必须以下划线开头。如果JSON Feed不能满足您的需求，您还可以提出自己的feed格式，这应该不难。

具有两个已发布域事件的示例JSON Feed可能如下所示：

 {

  "version" : " https://jsonfeed.org/version/1 " ,

  "title" : "user service events" ,

  "feed_url" : " http://userservice.myapi.com/events " ,

  "next_url" : " http://userservice.myapi.com/events?offset=2 " ,

  "items" : [

    {

      "id" : "42" ,

      "url" : " http://userservice.myapi.com/user/123 " ,

      "date_published" : "2020-05-01T14:00:00-07:00" ,

      "_type" : "NameChanged" ,

      "_data" : {

        "oldName" : "John Foo" ,

        "newName" : "John Bar"

      }

    }, {

      "id" : "43" ,

      "url" : " http://userservice.myapi.com/user/789 " ,

      "date_published" : "2020-05-02T17:00:00-03:00" ,

      "_type" : "UserDeleted" ,

      "_data" : {

        "name" : "Anna Smith" ,

        "email" : "anna@smith.com"

      }

    }

  ]
 }

第一个事件(ID为42 )指示用户资源/ user / 123的名称已更改。在_data块中，我们提供了一些可能对订户有用的附加事件信息。第二个事件表明资源/ user / 789已被删除， _data块包含已删除的用户数据。 _type和_data没有以JSON Feed格式定义，因此以下划线(JSON Feed扩展格式)开头。

提要属性next_url可用于提供某种分页。它告诉客户端在当前提要中的所有事件都已处理后，在哪里可以查找更多事件。我们的提要仅包含两个事件，因此我们告诉客户端使用偏移量参数2调用提要端点以获取下一个事件。

一般注意事项

如果您使用JSON Feed或使用自己的Feed格式，则在构建用于发布事件的Feed时应考虑以下一些常规事项：

提要项是不可变的

提要项表示域事件，它们是不可变的。必要时，客户可以使用唯一的Feed项目ID来检查他们是否已经处理过Feed项目。

Feed项目订单未修改

提要中项目的顺序不变。较新的项目会附加到Feed的末尾。

客户应该只能请求到目前为止尚未处理的提要项。

为避免客户需要一遍又一遍地处理所有提要项以查看是否有新项(例如，通过检查date_published项属性)，提要应提供一种仅返回新项的方法。使用JSON Feed时，可以通过next_url属性完成。

下图试图显示可能的next_url行为：

在第一个Feed请求中，只有两个事件可用。两者均由服务器以及包含偏移量参数2的next_url一起返回。客户端处理完两个提要项目后，客户端将使用偏移量2请求下一个项目。没有新项目可用，因此没有内容的空提要服务器返回一个新的next_url 。客户端会记住先前的next_url，并在稍后再重试该请求。这次返回的是新项目，其更新的next_url包含偏移量3。

当然，您可以想出不同的方法来达到相同的结果。