RESTful 子类型资源答案

【问题标题】：RESTful subtype resourceRESTful 子类型资源
【发布时间】：2012-01-10 06:30:00
【问题描述】：

一个最佳实践问题。如果您正在设计 RESTful 接口，您将如何区分子类型。例如。您的应用程序有动物（每只动物由其animalId 标识）具有狗和鸟的子类型，其中每个子类型都有其特定的子资源。例如。狗有尾巴长度和鸟翼长度（不管它是什么）。您会选择这些（或者您有更好的方法）中的哪一个？

1)
/animals/{animalId}/tail-length (400 when animal is bird)
/animals/{animalId}/wings-length (400 when animal is dog)

2)
/dogs/{animalId}/tail-length
/birds/{animalId}/wings-length

3)
/animals?type=dog/{animalId}/tail-length
/animals?type=bird/{animalId}/wings-length

【问题讨论】：

标签： rest

【解决方案1】：

假设不同子类之间没有 ID 共谋，我会推荐以下方法。

GET /animals/:id

有这样的回应。（这个例子是 JSON，但也可以是 XML/etc）

{
  "id": "xyz",
  "type": "dog",
  "tailLength" 400
}

这使它保持简单和 RESTful。

【讨论】：

好的，我同意这一点。另一个问题。如果你有一些特殊类型的子实体呢？例如。 /animal/:id/subentity/:sid （例如只有狗）。那么如果id下的animal是bird，你返回400 ... or?

【解决方案2】：

这真的是个人喜好问题。

我个人避免像选项 3 那样将信息放入查询字符串中，因为我倾向于将查询字符串用于非分层信息。（对this question 的接受回答说前两个更正确，而最赞成的回答说这真的无关紧要。）

缓存也是一个因素，因为代理可能不会缓存包含查询字符串的资源（请参阅Google's advice on leveraging proxy caches）。

我想我会选择第二个，或者可能是混合 (/animals/dogs/...) 来指示资源的层次结构，但这取决于你。

【讨论】：