我正在建立一个测验。用户可以选择一个主题并回答5个问题。在每个问题之后,他们会查看答案。我试图坚持这个工作流程的严格RESTful表示,但不能真正解决网址方案。例如:
用户Joe选择了主题运动并准备好看第一个问题。网址是
user/joe/subject/sport/question/1
当他提交答案'B'(它是一个多项选择测验)时,Joe正在创建一个新的答案,我们POST到
user/joe/subject/sport/question/1/answer/B
在中查看正确答案之前
user/joe/subject/sport/answer/1
然后我们在
查看下一个问题user/joe/subject/sport/question/2
这显然太复杂了。您将如何以RESTful方式处理此问题?
答案 0 :(得分:1)
对我来说,REST服务的基本思想是“资源”。首先,您需要确定您的资源。
所以有一个用户,她开始一个新的测验。
然后用户选择体育问题,因此您更新测验以包括随机(服务器选定)问题。
用户回答:
现在冲洗并重复。
我们获得的资源:
答案 1 :(得分:1)
从this presentation开始。它是RESTful API设计的绝佳资源。考虑到这一点,这里有一些开始的建议:
RESTful URL具有隐式层次结构。从URL中获取用户信息。它属于HTTP标头。
/subject/sport/question/1
/subject/sport/question/1/answer/B
/subject/sport/answer/1
/subject/sport/question/2
我没有看到subject
部分添加的任何有用信息。 subject
由(在您的示例中)sport
标识。
/sport/question/1
/sport/question/1/answer/B
/sport/answer/1
/sport/question/2
类别应为复数。
/sports/questions/1
/sports/questions/1/answers/B
/sports/answers/1
/sports/questions/2
当你回答问题时,你没有POST到添加一个新的答案资源(即,定义一个新的可能答案)。你不是在发布现有资源吗?
您没有提及有关HATEOAS的任何信息。如果您真的要实施REST,那么您应该执行providing "next" links in the hypermedia.
答案 2 :(得分:0)
我会完全删除路线中的/user/joe
。您可以使用Devise,Authlogic或其他一些身份验证框架来获取current_user。
否则这对我来说没问题,因为它只有两个足够可读的巢穴。所以你有:
GET subjects/sports/questions/1
POST subjects/sports/questions/1 # pass along params with {:answer => 'B'}
GET subjects/sports/answers/1