使用REST来草稿，发布和版本化资源

Question

我正在开发一个Web服务，所有中间更改都应进行版本控制（草稿），并且用户可以发布（实时发布其更改）。为了使用户能够继续使用较旧的版本（出于兼容性方面的考虑），用户也应该能够获得较旧的状态。

这是我当前设计的样子

+------------------+-------------------------------------------+--------------------------------------------------------------+-------------------------------------------------+
|      action      |                  request                  |                            response                          |                state of resource                |
+------------------+-------------------------------------------+--------------------------------------------------------------+-------------------------------------------------+
| create a post    | post                                      | status=201 id=123 and version=v1                             | resource created with version v1                |
| update the post  | put with id=123 and version=v1            | status=200 id=123 and version=v2                             | new version of resource created with version=v2 |
| update the post  | put with id=123 and version=v2            | status=200 id=123 and version=v3                             | new version of resource created with version=v3 |
| update the post  | put with id=123 version=v1                | status=409 and body indicating user is editing stale version |                                                 |
| publish the post | put with id=123 version=v2 action=publish | status=200 id=123 version=p1 (p indicating published)        | new version created with version=p1             |
| get all versions | get list with id=123 status=all           | status=200 and v1,v2,p1 in the body                          | no change                                       |
+------------------+-------------------------------------------+--------------------------------------------------------------+-------------------------------------------------+

以上内容是否遵循其他架构？ 我担心的特定问题是

1. 此处Put不具有幂等性，因为每次执行此操作都会创建一个新版本。

2. 用户必须知道action = Publish才能发布文章。是否可以在put / get / post响应正文中的客户端IMO上获得此信息，我们应该告诉所有支持的操作，例如

{
  "body": {...}
  "actions": [
    {
      "type": "publish",
      "uri": "/order/123/publish"
    },
    {
      "type": "save",
      "uri": "/order/123/save"
    },
    {
      "type": "archive",
      "uri": "/order/123/archive"
    }
  ]
}

1. 有什么我想念的吗

对细节是否过于草率？

Answer 1

鉴于您使用的是波多黎各风格，我建议以下做法：

1. 具有一个始终代表最新版本的uri。例如/order/123。
2. 创建具有从RFC5829到其他版本的关系类型的链接。示例：version-history，latest-version，predecessor-version，successor-version。仅使用所需的链接关系。不同的版本只是不同的资源。
3. 您可以使用属性（例如action）将资源标记为public或draft，而不是使用isPublic。如果设置为true，则该版本将成为公共版本。具有该状态的最后一个“版本”将变为真正的“实时”版本。

解决PUT幂等性问题

鉴于PUT每次运行时都会创建一个新的“版本”，它仍然是幂等的吗？我认为这很难回答。 2个PUT请求的效果是否与1个相同？

如果考虑HTTP访问日志，则2个相同的PUT请求也将导致2个条目。我真的不知道该如何调和，但我的想法是：

1. 2个相同的PUT请求仍会创建预期状态。对主要资源的更新。现在有一个额外的（版本化）资源，但这也许并不重要吗？
2. 如果尚未真正更改资源，则可以选择不创建新版本的资源，从而完全规避了此问题。