RESTful API 设计：PUT 还是 POST 用于创建多对多关系？

Question

对于设计和创建 RESTful API，会出现以下问题：

该 API 支持 GET（用于查询）、POST（用于创建）、PUT（用于更新）和 DELETE（用于删除）。

让我们假设在数据库中我们有一个文章和一个商店都已经存在。

现在我们需要一个 rest 调用来将文章实例链接到商店实例。以下哪个解决方案是最好/最干净的 REST 设计：

1. /shop/id/article/id/ --> 带有 POST
2. /shop/id/article/id/ --> 使用 PUT
3. /shoparticlerelation/ --> 带有 POST（主体中带有 id 的对象）
4. /shoparticlerelation/ --> 使用 PUT（主体中带有 id 的对象）

如果没有明确的答案或所有解决方案都同样好，如果有明确的理由，这也可能是一个有效的答案。

Answer 1

我假设在这种情况下，您已经有一个shops 的集合和一个 s 的集合article，而您只是希望将两个链接在一起。

一种选择是公开更多的数据库，如呈现此链接的“资源”，并具有类似的操作

POST /shopArticleLinks HTTP/1.1

{ "shop"  : xxx,
  "article: YYY
}

我个人希望将其作为商店和/或物品在更自然的庄园中的财产公开，例如

PUT /shop/<ID> HTTP/1.1

{ /* existing details */
  "articles": [ /* list of articles */ ]
}

我在那里使用过 JSON，但当然可以使用您想要使用的任何格式。我也坚持使用 PUT，如您所说，但请记住，使用 PUT，您应该发送新修改版本的完整替代品，PATCH 可用于发送部分更新，但您需要考虑如何做那，可能像

PATCH /shops/<ID>/articleLinks HTTP/1.1

{ "add"   : [],
  "remove : []
}

不要忘记服务器端，您可以查看articles所引用的内容并确保它们具有正确的反向指针。

_其他想法

关于第二种方法，您将链接公开为shop和/或article资源的属性。请记住，当您更新给定shop中的链接时，相应的链接articles也会更新，这是完全可以接受的（在这种情况下相当合适）。