Question

大家好，

我是REST和Web API的新手。我对如何为我的资源设计URI感到困惑。

鉴于我的域名包含以下资源：博客，帖子和用户。

Blog (1) ------ (0..*) Post (0..*) ------ (1) User

博客可以有很多帖子，每个帖子都与一个博客相关联。用户可以拥有多个帖子，每个帖子都与一个用户相关联。

对于博客和用户资源，URI如下所示：

GET /blogs - get list of all blogs
GET /blogs/{id} - get blog by id
POST /blogs - create new blog
PUT /blogs/{id} - update blog
DELETE /blogs/{id} - delete blog

GET /users- get list of all users
GET /users/{id} - get user by id
POST /users - create new user
PUT /users/{id} - update user
DELETE /users/{id} - delete user

但邮政资源怎么样？如何处理协会？我正在考虑以下备选方案 - 哪些是正确的，为什么？

- 通过博客获取所有帖子

1. GET /blogs/{id}/posts
or
2. GET /posts?blogid={id}

- 在博客中创建新帖子

3. POST /blogs/{id}/posts
or
4. POST /posts (here I would then in the payload send the IDs of the resources this post is associated with. BlogId and UserId)

- 按博客和用户

获取所有帖子

5. GET /blogs/{id}/posts?userid={id}
or
6. GET /posts?blogid={id}&amp;userid={id}

如果有人能指出我在这方面的正确方向，我将不胜感激。

Answer 1

由于帖子总是与博客和用户ID相关联，我会选择选项1,3和5：

GET /blogs/{id}/posts
POST /blogs/{id}/posts
GET /blogs/{id}/posts?userid={id}

Answer 2

您应该问自己的第一个问题是，您的API是真正的REST是多么重要？它实际上要比实现这一目标更加繁琐。

您的API是否仅由您自己的软件\组织使用？
您的API是否附有文档？

如果对上面的1或2的答案是真的，那么真正RESTful的价值是值得怀疑的......它与REST的全部或全无，所以要么你全力以赴，要么你不担心。

要使API成为真正的REST API，必须从单个入口点发现它（请参阅此处：http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven）。每次调用都应该返回有关可以在该资源上进行的其他相关调用的信息..通常通过某种链接，这是一种可能的结构：

{
    "Id" : 1,
    "Identifier" : "123's First Blog",
    "links" : [
        {
            "rel": "http://myapi/res/posts",
            "href": "http://myapi/blog/1/posts"
        },
        {
            "rel": "http://myapi/res/users",
            "href": "http://myapi/user/123"
        }
    ]
}

rel是资源摘要\定义的链接，href应该指向api本身。

无论如何，所有这一切的要点是，如果你确实想要真正的RESTful，那么让资源和uris之间的链接决定设计。想想你将如何从一个起点发现每个电话的细节，结构应该像TDD软件设计一样显示出来。

如果您不需要RESTful，那么事情会变得更加简单。只需为您，您的架构和开发人员以最自然的方式设计API。如果你正确地记录了事情，那么这将导致更高效的API和更快开发的API。

马里奥对这个问题的回答是合理的，我也赞成这些选择。我只是觉得你应该知道伴随这种情感的整个故事。

如果这没有意义，或者您想了解更多信息，请发表评论，我会尽力帮助：）

具有相关资源的REST服务的正确URI设计是什么

2 个答案: