HasMany RESTfull (或反RESTfull)设计？

Question

所以我读了很多关于RESTfull设计的文章--特别是关于资源的。

以用户、Posts和Comments的典型示例为例，其关系如下：

用户-(HasMany)

人们一开始可能会想要揭露这样的事情：

GET /users               GET /posts               GET /comments 
POST /users              POST /posts              POST /comments 
GET /users/id            GET /posts/id            GET /comments/id
PUT /users/id            PUT /posts/id            PUT /comments/id
DELETE /users/id         DELETE /posts/id         DELETE /comments/id

但是，假设我想要一个特定用户发布的某篇文章的所有评论。我需要做的事情是：

GET /users/id
   > someUser
   > var postIds = someUser.posts()
GET /posts?id=<postIds[0]>&id=<postIds[1]>&...
   > somePosts
   >  **application user inspects posts to see which one they care about**
   > var postOfInterest = somePosts[x]; 
   > var postId = postOfInterest.id;
GET /comments?id=postId
   > someComments (finally)

假设我只关心一个帖子或评论在它的所有者的上下文中。假设不同的资源结构可能(或不可能？)更自然：

GET /users
POST /users  
GET /users/id   
PUT /users/id
DELETE /users/id

GET /users/id/posts
POST /users/id/posts
GET /users/id/posts/id
PUT /users/id/posts/id
DELETE /users/id/posts/id

GET /users/id/posts/id/comments
POST /users/id/posts/id/comments
GET /users/id/posts/id/comments/id
GET /users/id/posts/id/comments/id
GET /users/id/posts/id/comments/id

对我来说，这可能是对资源的更好的描述。我所需要的就是：

GET /users/id/posts
   > somePosts
   > **application user inspects posts to see which one they care about**
   > var postOfInterest = somePosts[x];
   > var postId = postOfInterest.id;
GET /users/id/posts/postId/comments
   > someComments

这看起来更像是导航文件系统而不是前面的方法--但是我不知道它的RESTfull (也许这就是REST试图摆脱的东西)，因为为了访问注释资源，我需要知道它属于哪个用户和哪个帖子。但前者需要3个请求，而后者只需要2个请求。

有什么想法？

Answer 1

好的REST有相当一部分是意见，但我想说的是，第二种方法通常更多地是"RESTful“。

基本上，您需要REST和文件系统中的层次结构，比如导航，而不是查询参数。尤其是如果您遵循类似于HATEOS的API，因为有人可以导航您的API。

Answer 2

在第二个例子中，有GET /users/id和GET /users/id/posts是很重要的，这样当请求用户的信息时，它也不包括所有的帖子(或他们的is )。第二项要求也会退回他们的职位。通常，用户在一个论坛上有数千条帖子。

缺点是api用户总是必须知道它想要得到评论的帖子的作者。他基本上会向您的服务器发出“给我该用户并给我他/她的帖子”的请求，这意味着您的服务器将对该用户进行查询，然后选择他的帖子。相反，对于您的用户和服务器来说，有单独的请求要方便得多--“给我那个用户”、“给我那个帖子”和“给我那个评论”。这意味着您必须分别存储用户、帖子和评论，对于每个帖子/评论存储它的作者的id，这样您就可以选择他们的作者的帖子/评论(“给我这个用户的帖子”，或者简单地“给我这个帖子”)

我个人会同意这种请求的变体

GET user
GET post
GET comment
...

对于每个请求，我都会实现一个where子句，它将为api的用户提供更多的选项来做出特定的选择。例如，GET posts where userId='myID'。它可以用url查询参数 (如http://myapi.mydomain.com/post?userId=user1 )或在标头内实现。它将返回该用户的帖子列表。您还可以为post的ID - http://myapi.mydomain.com/post?id=123使用where子句，这将只返回这个帖子。注意，对于第一种情况--当您获取一个帖子列表时--您只能为这些帖子返回某种简短的信息(比如id、author、汇总.)并要求向post?id=id提供完整的post内容的附加请求。

拥有这个实现至少会给您两个好处：

• api的用户只需要知道一个id就可以得到一些信息-- postID来获取一个帖子的内容/注释，userId来获取该用户的所有帖子/注释。
• 选择是在服务器上完成的，因此在网络上传输的数据较少，这意味着响应速度更快(如果最终用户处于移动计划或其他情况下，则可能会降低成本)

在我看来，这个实现为с提供了松散耦合的对象(用户、帖子、注释)和更灵活的查询。