URL,正文或标题中的RESTful API子类型?

sie*_*z0r 6 rest restful-url

我对哪个RESTful设计更好而感到困惑.

对于API我有三种类型; Question,AnswerStudent.该Question类型有两种亚型; MultipleChoiceOpen.该Question类型将来可能会有更多的子类型.请注意,子类型具有公共和不同(可选)属性.Answer适用于所有问题.

我已经看到过类似的问题(REST Api中的建模对象继承,如何使用继承建模RESTful API?),给定的答案指向使用通用URL并指定正文中的类型.但是,我不觉得答案是否具有权威性(没有提及最佳实践,也没有提及很多赞成等).

我正在寻找基于事实而非意见的权威,可靠的答案.

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

输入网址

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

[
  {
    "url": "http://example.com/questions/multiplechoice/1",
    "name": "example question"
  },
  {
    "url": "http://example.com/questions/open/2",
    "name": "another question"
  }
]
Run Code Online (Sandbox Code Playgroud)

可以使用请求一系列多项选择题GET /questions/multiplechoice.

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

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

这种方法的缺点(我认为)是当学生提交答案时,URL会因问题而异.POST /questions/multiplechoice/1/answersPOST /questions/open/2/answers.

输入正文

请求所有问题的列表保持不变,GET /question.输出也是一样的.

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

创建新的多重选择问题也意味着发布类型.POST数据将是:

{
  "type": "multiplechoice",
  "name": "example question"
}
Run Code Online (Sandbox Code Playgroud)

好处是URL保持简单,将来不太可能改变.缺点是一个请求处理程序需要基于body将请求(使用某种映射)请求分派给特定于该类型的其他处理程序.

答案是使用通用URL提交的: POST /questions/:question_id/answers

输入标题

Content-TypeAccept标头可用于代替type参数.

获得所有问题的清单:GET /questions.

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

这种方法类似于体内入路方法.另一个缺点是,这涉及到自定义的mime类型,如果你问我,这些类型并不是很明显.

And*_*res 0

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

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

  • 正如问题所述“我正在寻找基于事实而不是观点的权威、可信的答案。” (2认同)