URL、正文或 header 中的 RESTful API 子类型？

Question

我对哪种 RESTful 设计更好感到有些困惑。

对于 API，我有三种类型； Question , Answer和 Student . Question type 有两个子类型； MultipleChoice和 Open . Question type 将来可能会有更多的子类型。请注意，子类型具有共同和不同(可选)的属性。 Answer适用于所有问题。

我见过类似的问题( Modeling Object Inheritance in a REST Api ， How to model a RESTful API with inheritance? )，给定的答案指向使用通用 URL 并在正文中指定类型。但是，我不觉得答案是权威的(没有引用最佳实践，没有很多赞成票等)。

我正在寻找基于事实而非观点的权威、可信的答案。

我将在下面解释可能的设计。

输入网址

可以使用 GET /questions 请求所有问题的列表.这将返回一个包含问题摘要的 JSON 列表:

[
  {
    "url": "http://example.com/questions/multiplechoice/1",
    "name": "example question"
  },
  {
    "url": "http://example.com/questions/open/2",
    "name": "another question"
  }
]

可以使用 GET /questions/multiplechoice 请求选择题列表。 .

可以使用 POST /questions/multiplechoice 创建新的多项选择题

服务器端这些 URL 映射到不同的请求处理程序。这样做的好处是不需要检查来检查要创建/返回的类型，它隐含在 URL 中。

这种方法的缺点(我认为)是当学生提交答案时，问题的 URL 会有所不同。 POST /questions/multiplechoice/1/answers和 POST /questions/open/2/answers .

输入正文

请求所有问题的列表保持不变， GET /question .输出也将是相同的。

请求选择题列表意味着过滤，所以这将是 GET /questions?type=multiplechoice .

创建一个新的多项选择题也意味着发布类型。 POST 数据将是:

{
  "type": "multiplechoice",
  "name": "example question"
}

这样做的好处是 URL 保持简单并且将来不太可能更改。缺点是一个请求处理程序需要将基于主体的请求分派(dispatch)(使用某种映射)到特定于该类型的其他处理程序。

使用通用 URL 提交答案: POST /questions/:question_id/answers
输入标题
Content-Type和 Accept可以使用 header 代替 type范围。

获取所有问题的列表: GET /questions .

要获得所有多项选择题的列表: GET /questions , Accept设置为 application/app.multiplechoice+json .

这种方法类似于输入法。额外的缺点是这涉及自定义 mime 类型，如果你问我，这并不是很明显。

Answer 1

MultipleChoice 和 Open 是 Question 的子类型。因此，应该有包含/question/multiplechoice 和/question/open 的 url。

关于您不希望收到基于意见的答案，REST 不是 JEE 那样的标准，也不是 Spring 那样的实现。这是一种风格，如巴洛克式或哥特式。所以，你只会得到意见作为答案。