在RESTful API中实现命令模式

我正在设计HTTP API，希望使其尽可能地具有RESTful风格。

有些动作的功能会散布在一些资源上，有时需要撤消。

我以为自己，这听起来像是命令模式，但是我如何将其建模为资源呢？

我将介绍一个名为XXAction的新资源，例如DepositAction，它将通过这样的方式创建

POST /card/{card-id}/account/{account-id}/Deposit
AmountToDeposit=100, different parameters...

这实际上将创建一个新的DepositAction并激活它的Do / Execute方法。在这种情况下，返回201 Created HTTP状态表示操作已成功执行。

之后，如果客户希望查看操作细节，则可以

GET /action/{action-id}

我猜应该阻止Update / PUT，因为此处不相关。

为了撤消操作，我想到了使用

DELETE /action/{action-id}

实际上将调用相关对象的Undo方法，并更改其状态。

假设我只对一次“撤消”感到满意，而无需重做。

这种方法可以吗？

有什么陷阱，不使用它的原因吗？

从客户的观点看是否明白？

您正在添加一个令人困惑的抽象层

您的API开始时非常干净简单。HTTP POST使用给定的参数创建一个新的存款资源。然后，通过介绍“操作”的概念脱离轨道，该操作是实现的细节而不是API的核心部分。

作为替代方案，请考虑此HTTP对话...

POST /卡/ {卡ID} /帐户/ {帐户ID} /存款

AmountToDeposit = 100，不同的参数...

创建201

位置= /卡/ 123 /帐户/ 456 /存款/ 789

现在，您要撤消此操作（从技术上讲，在平衡的会计系统中不应允许此操作，但是嘿）：

删除/ card / 123 / account / 456 / Deposit / 789

204没有内容

API使用者知道他们正在处理“存款”资源，并能够确定允许对其执行哪些操作（通常通过HTTP中的OPTIONS）。

尽管今天通过“操作”执行删除操作，但不能保证当您将此系统从C＃迁移到Haskell并维护前端时，“操作”的次要概念将继续增加价值，而存款的主要概念当然可以。

编辑以涵盖删除和存款的替代方法

为了避免删除操作，但仍然有效地删除了存款，您应该执行以下操作（使用通用交易进行存款和取款）：

POST /卡/ {卡ID} /帐户/ {帐户ID} /交易

Amount = -100，不同的参数...

创建201

位置= /卡/ 123 /帐户/ 456 /交易/ 790

创建一个具有完全相反数量（-100）的新事务资源。这具有平衡帐户回到0的作用，从而使原始交易无效。

您可以考虑创建一个“实用程序”端点，例如

POST / card / {card-id} / account / {account-id} / Transaction / 789 / Undo <-Bad！

获得相同的效果。但是，这通过引入动词来破坏URI的语义，使其成为标识符。您最好不要在标识符中使用名词，并且将操作限制在HTTP动词上。这样，您可以轻松地从标识符创建一个永久链接，并将其用于GET等。

REST存在的主要原因是对网络错误的恢复能力。为此，所有操作应是幂等的。

基本方法似乎是合理的，但是您描述DepositAction创作的方式听起来并不等效，应该固定。通过让客户端提供将用于检测重复请求的唯一ID。因此创作将变为

PUT /card/{card-id}/account/{account-id}/Deposit/{action-id}
AmountToDeposit=100, different parameters...

如果使用与先前相同的内容对同一URL进行另一个PUT，则如果内容相同，则响应应该仍然是，201 created如果内容不同，则响应为错误。这使客户端可以在失败时简单地重新发送请求，因为客户端无法确定请求或响应是否丢失。

使用PUT更有意义，因为它只写资源并且是幂等的，但是使用POST也不会造成任何问题。

为了查看交易细节，客户将GET使用相同的URL，即

GET /card/{card-id}/account/{account-id}/Deposit/{action-id}

并撤消它可以删除它。但是，如果它确实如示例所示与钱有关，我建议尽管添加问责制，但要添加“已取消”标志来放置它（仍然存在创建和取消的交易的痕迹）。

现在，您需要选择一种创建唯一ID的方法。您有几种选择：

1. 在必须包含的交换中较早地发出客户端特定的前缀。
2. 添加特殊的POST请求以从服务器获取空白的唯一ID。该请求不必是幂等的（也可以不是真的），因为未使用的ID不会真正引起任何麻烦。
3. 只需使用UUID。每个人都使用它们，似乎没有人对基于MAC的和随机的都没有任何问题。