使用 Jersey REST 维护事务流

Question

我对 REST 世界很陌生，我们正在尝试将我们的应用程序迁移到基于 REST 的架构。我们正在做一个概念证明，我们需要拿出一个工作证明，证明我们要实现的目标可以使用 REST 来完成。

在我们的架构中，前端屏幕将使用 Angular 并调用 REST 服务来打开客户会话并在该会话中执行/维护事务，当会话完成时，会话详细信息（即其中的所有客户事务客户会话）将被发送到数据库提交。我们只想在客户完成会话中的所有事务后写入数据库。换句话说，只有在会话结束时才会提交到数据库。

我希望获得一些关于如何最好地在我们的 Java 类中执行以下步骤的指导。

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

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

2) 客户交易在会话内执行。对于每个处理的事务，事务 POST 服务用于将事务信息与会话信息一起保存。

问题 --> 在我的 Java 类中，维护此事务信息的最佳方式是什么，以及如何最好地将这个事务信息与之前创建的会话信息相关联会话 POST 信息？客户端将维护会话 ID，但在服务端，我需要能够将事务与会话 ID 映射，以便我可以发送回包含会话信息和该会话中的事务的组合会话有效负载。

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

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

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

任何指针将不胜感激。

谢谢 阿里。

Answer 1

基本上这个问题并不容易，需要大量的写作，但我会尽力回复。

首先要记住 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/
   

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

   响应：返回一个新添加的项目及其唯一 ID

3. 为购物车付款（提交交易）

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

   请求：必须包含shoppingCartID

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

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

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

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

编辑（在 cmets 讨论后）

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

我看到的选项：

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

这完全取决于您要实现什么。我无法想象可以简单地删除未提交的事务并且什么都没有发生的情况 - 似乎必须进行持久存储。不过，上面的想法也可能有用。