REST资源粒度

Question

我想了解对资源粒度的看法。比如说，我有一个叫“杂志”的领域实体。但是有不同类型的杂志，包括“体育”、“自然”、“汽车”、“电脑”和“飞机”等等。当我想创建一个新的“体育”杂志时，我是否应该使用这样的结构：

• 放置/magazines
• PUT /运动-杂志
• 放/杂志/运动

当我想要一本特定的体育杂志时，我是否应该说：

• 获取/杂志/{id}
• 获取/运动-杂志/{id}
• 获取/杂志/体育/{id}

如果我想获得2001年的体育杂志，我是否应该使用：

• 获取/magazines?type=sports&year=2001
• 获得/运动-杂志?年份=2001年
• 获得/杂志/体育?年份=2001年

最后，如果我想返回2001年1月出版的每本类型的杂志有多少页，我会怎么做？我是否需要为此创建一个新的页面资源？或者提出两个独立的请求或者别的什么？其中第一项如下：

• 获取/magazines/pages?type1=sports&type2=nature&year=2001&month=01
• 获取/sports-magazines/pages?type=nature&year=2001&month=01

考虑到这些情况，您将如何建模您的资源？

Answer 1

我有一个叫“杂志”的领域实体。但是有不同类型的杂志，包括体育，自然，汽车，电脑和飞机等。

重要的是要理解:资源不是域实体。资源模型是位于域模型前面的外观。

例如，请注意，这个资源(REST资源粒度)不仅描述了您的问题，还描述了我的答案。

PUT可能不是您想要的“创建新资源”，除非客户端已经知道应该为新资源使用什么URI。PUT请求的目标URI与我们希望稍后用于获取数据的URI相同。

PUT /magazines/{id}
GET /magazines/{id}

如果我们不希望客户端知道URI是什么.嗯，我们没有一个HTTP方法，这意味着这一点，所以我们回到使用POST (参见菲尔丁，2009年)。

POST /magazines

201 Created
Location: /magazines/12345

注意，机器并不关心创建的资源的URI是否与POST请求的目标URI相匹配。

REST实际上并不关心用于资源标识符的拼写约定(就像机器不关心用于变量名称的拼写约定一样)。

GET /magazines?type=sports&year=2001
GET /sports-magazines?year=2001
GET /magazines/sports?year=2001
GET /magazines/sports/year=2001
GET /magazines/sports/2001

这些都很好，是有权衡的。在查询字符串中编码的键值对使使用HTML表单创建URI更容易，使用路径段则使相对解析更容易。

我想返回每种类型的杂志2001年1月出版的页数。

使用该信息创建一个新URI是很好的。扩展现有资源的架构以包含该信息也很好。