使用 Jersey REST 维护事务流

Maintaining a transaction flow using Jersey REST

我是 REST 世界的新手,我们正在尝试将我们的应用程序迁移到基于 REST 的架构。我们正在研究概念证明,我们需要提出一个工作证明,证明我们可以使用 REST 来完成我们要实现的目标。

在我们的架构中,前端屏幕将使用 Angular 并调用 REST 服务来打开客户会话和该会话中的 perform/maintain 交易,当会话完成时,会话详细信息(即客户会话中的所有客户交易)将被发送以提交给数据库。我们只想在客户完成会话中的所有交易后写入数据库。换句话说,只有在会话结束时才会提交到数据库。

我希望得到一些关于如何在我们的 Java 类.

中最好地执行以下步骤的指导

1) 浏览器发起打开新客户会话的请求。会话 POST 服务用于生成新的会话 ID。会话 ID 作为响应发送回浏览器。

问题 --> 在我的 Java 类 中维护此会话 ID 值的最佳方法是什么?

2) 客户交易在会话中进行。对于处理的每个事务,事务 POST 服务用于保存事务信息和会话信息。

问题-->在我的Java类维护这个交易信息最好的方法是什么,怎么做最好我把这个交易信息和之前会话创建的会话信息关联起来 POST 信息?客户端将维护会话 ID,但在服务端,我需要能够将事务与会话 ID 映射,以便我可以发回包含会话信息和该会话中的事务的组合会话有效负载。

3) 客户可以执行更多交易,并且执行的每个交易都是一个交易 POST 请求,该请求必须与之前创建的会话 ID 相关联。执行的每个额外事务都必须与服务端的会话 ID 相关联,这样当我对会话 ID 执行 GET 操作时,我需要获取会话详细信息以及该会话中的所有事务。

4) 最后,当会话完成时,来自会话的信息和服务端的会话有效负载(连同所有事务​​)将提交给数据库。

我只是在寻找一些关于如何使用我的 Java 类 和 Jersey REST 最好地做到这一点的一般指导。

如有指点,将不胜感激。

谢谢 阿里.

基本上这个问题并不简单,需要大量的写作,但我会尽力回答。

首先请记住 REST 是无状态的 - 这意味着没有会话并且客户端需要通过 每个 请求进行授权。这是一个单独的主题,但 REST 中一个不错的授权方法是 JSON Web Token.

其次,REST 是关于名词的,而不是动词。因此,您应该避免使用像 /session/{sessionId}/close/ 这样的 URL,而是尝试使用名词和默认 HTTP 操作对域建模:POST(创建)、PUT(更新)、GET(读取)、DELETE(删除)。

我想会话和交易只是一个抽象概念,我将向您展示如何在购物车示例中对其建模。在所有示例中,我都将 URL - with /users/{userId}/ 前缀加倍,以表明您可以通过多种不同方式引用资源

  1. 创建购物车(创建会话)

    POST /shopping-carts/
    POST /users/{userID}/shopping-carts/ 
    

    请求:可能为空或应包含有关购物车的必要详细信息

    响应:必须包含新创建的 shoppingCartID

    {
       "shoppingCartID": "1qaz2wsx"
       ... 
    }
    
  2. 将商品添加到购物车(创建交易)

    POST /shopping-carts/{shoppingCartID}/items/
    POST /users/{userID}/shopping-carts/{shoppingCartID}/items/
    

    请求:包含有关正在添加的项目的详细信息

    响应:returns 一个新添加的项目及其唯一 ID

  3. 支付购物车费用(提交交易)

    POST /payments/
    POST /users/{userID}/payments/
    

    请求:必须包含一个shoppingCartID

    {
        "shoppingCartID": "1qaz2wsx"
        ...
    }
    

    响应:包含有关新创建的付款的详细信息

    {
        "paymentId": "3edc4rfv"
        ...
    }
    

我知道这是一个笼统的答案,但很难对如此广泛的问题给出准确的答案。

编辑(在评论中讨论后)

在我看来,应该使用数据库在交易获得批准之前将其暂时保存在 table 中。即使您不想使用数据库,也强烈建议使用任何其他持久性存储 - 想象一下如果在交易未获批准时服务器重新启动会发生什么情况,您将丢失所有数据。

我看到的选项:

  • 记忆中。您可以编写具有同步访问的简单内存结构。在最简单的情况下,只需要普通的 HashMap 就足够了。请注意,以这种方式保存数据是有风险的,它们很容易被删除。
  • 使用文件系统。如果你不想使用数据库,你可以使用文件系统来保存未提交的事务数据。添加新事务后,它被写入文件。在提交时读取文件并将所有事务保存到数据库中。同步文件访问在这里也非常重要。当谈到数据格式时,你可以使用 JSON、XML,甚至是普通的 java 序列化。
  • 我想到的最后一个想法是使用内存数据库,例如 Redis。数据将在系统重新启动时被删除,因此它们不太可能被删除,但我认为这也不安全。这样的数据库比传统数据库更容易 use/maintain。

这完全取决于您要实现的目标。我无法想象这样一种场景,可以简单地删除未提交的事务而什么也没有发生——似乎持久存储是必须的。然而,上面的想法也可能有用。