我正在研究RestApi，我对选择一种路线犹豫不决。
我有User和Collection以及一些路线，例如：
GET /user
GET /collections
GET /collection/{id}
现在我需要为User添加路由，可以订阅Collection，那么最佳路线是什么？
POST collection/{id}/user/subscription ? POST /user/subscription/collection/{id} ? 例如，在我的数据库中，我有一个表格：
谢谢！
答案 0 :(得分：1)
在您的应用程序中，订阅的概念是用户和集合之间的关系。有很多方法可以处理它，但我会有一个像/collections/{collection-id}/subscriptions这样的URI。
要创建订阅，我会执行POST发送订阅请求有效内容中的集合的用户的标识符：
POST /collections/{collection-id}/subscriptions HTTP/1.1
Host: example.com
Content-Type: application/json
{"user": "{user-id}"}
将来，如果您需要为订阅添加其他属性（例如到期日期，状态等），则应在请求有效负载中发送它们同样。如果您假设正在执行请求的用户已经过身份验证并且是订阅该集合的用户，则您也可能不需要发送用户标识符。
对此请求的成功响应应包含201状态代码和Location HTTP标头：
HTTP/1.1 201 Created
Date: Fri, 14 Oct 2016 11:00:00 GMT
Location: http://example.com/collections/{collection-id}/subscriptions/{subscription-id}
要删除订阅，我会执行DELETE请求：
DELETE /collections/{collection-id}/subscriptions/{subscription-id} HTTP/1.1
Host: example.com
成功的操作应该会产生204状态代码的响应：
HTTP/1.1 204 No Content
Date: Fri, 14 Oct 2016 11:00:00 GMT
答案 1 :(得分：0)
取决于用例场景。如果客户端在尝试订阅之前在User资源上导航，则可能更像POST /user/subscription/collection/{id}这样做。如果相反（浏览馆藏并选择一个 - 或更多 - 订阅），请选择第一个。
此外，如果Subscription本身就是一个资源，那么它包含一个集合列表（？），如果您允许一次更新大量集合，那么{ {1}}可能是你的朋友：
查看RFC 6902（定义补丁标准），从客户端的角度来看，API可以被称为
PATCH可能不是与你的模特一对一匹配，但你得到了要点。