我一直在阅读有关RESTful服务的文章,我理解使用VERBS对资源的重要性。
但有一件事我不明白。如果我们需要调用不属于CRUD的特定操作会发生什么?
例如,考虑我想让猫跳。我们应该使用哪种格式?
以下是RESTful吗?
http://host/cats/123/jump
答案 0 :(得分:10)
如果cats/123
代表资源,那就这样考虑一下:该资源可以有多个状态(吃饭,走路,睡觉,跳跃,蹲便器, ...)。当您使用REST架构样式设计API时,您希望允许客户端应用程序对将更改其状态的资源发出允许请求。
在cats/123
的上下文中,您可以通过一系列POST请求执行此操作,这些请求将导致资源状态发生更改。利用REST中的超媒体功能,您可以创建一个类似于下面显示的请求和响应的流程。请注意,允许的链接会更改为对POST的响应。此外,客户端应用程序将编码到Links数组中包含的属性,而不是Href属性中包含的实际URI。
请求:
GET cats/123
响应:
{
"Color" : "black",
"Age" : "2",
"Links":[
{
"Food":"kibbles",
"Method":"POST",
"Href":"http://cats/123",
"Title":"Feed the cat"
},
{
"Scare":"yell real loud",
"Method":"POST",
"Href":"http://cats/123",
"Title":"Scare the cat"
}]
}
请求:
POST cats/123
{
"Food":"kibbles"
}
响应:
{
"Color" : "black",
"Age" : "2",
"Tummy" : "full"
"Links":[
{
"Sleep":"lap",
"Method":"POST",
"Href":"http://cats/123",
"Title":"Pet the cat"
},
{
"Scare":"yell real loud",
"Method":"POST",
"Href":"http://cats/123",
"Title":"Scare the cat"
}]
}
答案 1 :(得分:0)
对于纯净的Restful设计,我建议使用类似的东西
POST /cats/123/actions
的正文(操作的类型在request中定义:
{
"actionType": "jump",
"customActionParameter": "some value"
}
但这将是一个过大的杀伤力。 因此我发现更容易遵循Google Api Design Guide for Custom Methods:
POST /cats/123:jump
这是Google在其云基础架构Api中使用的方法
答案 2 :(得分:0)
请勿将HTTP动词与您域的状态机转换或操作相混淆。
Stripe的invoice workflow提供了一个很好的示例,说明了如何以一种轻松的方式表示状态转换或域操作。
对域模型的操作很可能由对状态或状态字段的修改(PUT或PATCH)表示,该修改将触发您自己代码的状态机内的工作流。例如,在您的示例中,跳跃动作也可能导致与3x步相同的状态,因此它可能是对高度或高度场的修改。然后,您的代码可能会实现某种类型的工作流管理或状态机,然后您可以根据请求的状态更改(而不是基于为实现该状态而执行的“操作”)发出自己的事件和验证规则。
答案 3 :(得分:0)
游戏晚了,但因为 REST 是关于你的资源状态,这也是可以接受的,如果有点冗长。这用形容词或名词替换动词(如@developerjack 所述,它经常与 HTTP 动词混为一谈)。
这种语法对于一组有限的自然状态可能更有意义。例如,使用我以前做过的调度程序: