[英]RESTful API Design: PUT or POST for creating many-to-many relationships?
对于设计和创建 RESTful API,会出现以下问题:
该 API 支持 GET(用于查询)、POST(用于创建)、PUT(用于更新)和 DELETE(用于删除)。
让我们假设在数据库中我们已经有一篇文章和一家商店。
现在我们需要一个 rest 调用来将文章实例链接到商店实例。 以下哪个解决方案是最好/最干净的 REST 设计:
如果没有明确的答案或所有解决方案都同样好,如果有明确的理由,这也可能是一个有效的答案。
我认为在这种情况下你已经拥有了一系列shop
和一系列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
中的链接也会更新,这是完全可以接受的(在这种情况下相当合适)。
/shop/id/article/id/
您不能使用它,因为在您想要链接它们时,此端点不存在(或至少不应该存在)。 将它们链接在一起应该定义此端点的操作。
/shoparticlerelation/
您不应该使用它,因为shoparticlerelation
不是资源/实体。 通常使用rest,每个命名的url段代表一个可以CRUD的资源。 /shops
是一个很好的例子,因此/articles
但这不是。
我建议如下:
定义以下端点
/shops
新店铺
/shops/id
在一家商店经营
/articles
新文章的文章
/articles/id
用于操作单个文章
然后将它们链接在一起,您可以执行所谓的PATCH请求,更新商店的文章或文章的商店:
PATCH /shops/1 HTTP/1.1
{
"attribute": "articles",
"operation": "add",
"value": "8" // the article id
}
和
PATCH /articles/9 HTTP/1.1
{
"attribute": "shops",
"operation": "add",
"value": "1" // the shop id
}
根据您的评论,我假设文章模型将商店列表作为属性,反之亦然,使此方法有效。
PATCH请求用于通过指定更新的方式和内容来修改现有资源。 这与PUT不同,因为PUT使用来自请求的值替换整个资源,但PATCH仅用于修改(而不是替换)资源。
为了在一个 API 调用中创建一个新玩家并将他们分配给一个团队,我决定使用以下格式。
[POST] /teams/123/players
我发现很难确定这是否是标准可接受的方法。
声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.