我对哪种RESTful设计更好而感到有些困惑。
对于API,我有三种类型; Question
,Answer
和Student
。 Question
类型有两种子类型; MultipleChoice
和Open
。 Question
类型将来可能会有更多的子类型。请注意,子类型具有公共和不同(可选)属性。 Answer
适用于所有问题。
我见过类似的问题(Modeling Object Inheritance in a REST Api,How to model a RESTful API with inheritance?),给定的答案指向使用通用网址并指定正文中的类型。但是我不觉得答案是否具有权威性(没有提及最佳实践,也没有提及很多赞成等)。
我正在寻找基于事实而非意见的权威,可信的答案。
我将在下面解释可能的设计。
使用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保持简单,将来不太可能改变。缺点是一个请求处理程序需要将基于body的请求(使用某种映射)请求分发给特定于该类型的其他处理程序。
使用通用网址提交答案:POST /questions/:question_id/answers
可以使用Content-Type
和Accept
标头代替type
参数。
获取所有问题的列表:GET /questions
。
要获取所有多项选择题的列表:GET /questions
,Accept
设置为application/app.multiplechoice+json
。
这种方法类似于体内入路方法。另外一个缺点是,这涉及到自定义的mime类型,如果你问我,这种类型并不是很明显。
答案 0 :(得分:0)
MultipleChoice和Open是Question的子类型。因此,应该有包含/ question / multiplechoice和/ question / open的网址。
关于您不希望根据意见收到答案的愿望,REST不是像JEE那样的标准,也不是像Spring那样的实现。这是一种风格,如巴洛克式或哥特式。所以,你只会得到意见作为答案。
答案 1 :(得分:0)
根据他们给出的Rest Api best Practice是最佳实践。在此 Rest是基于资源的,我们应该使用动词的标准,所以我认为按照上面的url,你的答案最相似。
For Get
E.g:- Get/questions/multiplechoice //// this case controller/action/id id(optional)
this route config will resolve this route
Get/questions/open
For post
E.g:- Post/questions/multiplechoice //// you can use same route for post/put/delete.
Post/questions/open