REST URL结构 - 资源ID可以在控制器之前运行吗？

ASP.NET MVC(以及一般的MVC)的标准模板似乎是{controller}/{action}/{id},但是,对于我正在进行的项目,我不确定这是否合适结构体.例如,如果我有一个控制汽车的应用程序,对我来说,拥有以下结构对我来说更有意义:

  {car-rego}/{controller}/{action}/{data etc}

这对我来说很有意义,因为汽车(由登记牌识别)是我们正在进行操作的资源,并且功能的逻辑分离被分离到控制器和动作中.这会导致URL如下:

/ESX-121/Power/On
/ESX-121/Speed/Set/100
/ESX-121/Speed/Current -- get the current speed (could be /ESX-121/Speed also)
/ESX-121/Turn/Left
/ESX-121/Speed/Set/90
/ESX-121/Power/Off

如果这遵循默认模式,它将如下所示:

/Power/On/ESX-121
/Speed/Set/ESX-121/100
/Speed/Current/ESX-121 -- get the current speed (could be /Speed/ESX-121 also)
/Turn/Left/ESX-121
/Speed/Set/ESX-121/90
/Power/Off/ESX-121

对我来说,第一个选项使得可读URL更有意义,资源标识符位于一个恒定的逻辑位置.例如/ Speed/Set/ESX-121/100向我建议,存在类型速度的资源,其标识符为ESX-121,实际情况并非如此,操作在汽车上.

你如何构建URL以及相关的控制器和动作来处理这种情况？您认为这是一个可接受的解决方案,还是有更好的方法来构建它？

从"哲学"的角度来看,存在一个很大的问题.

您似乎正在使用GET请求几乎所有内容,例如设置速度.REST背后的想法是,访问ESX-121资源可以让您了解其当前状态,在您的情况下,它的速度,方向,如果它等等.

在其URL处发布汽车的某些表示将有效地改变其当前状态.(例如,如果您使用XML进行表示,则可以发布

ESX-121100

改变它的速度.在ASP.net MVC下你会发布一个表格.

您要做的是将SOAP服务建模方式(面向操作或动词)应用于REST服务,这不是真正的想法.

可能很难"获得"REST的做事方式,并且它可能违背您在使用SOAP服务时所做的一切,但重要的是要牢记这些原则.

理论上,URL描述了一个资源,唯一可用的操作是通过GET(读取),POST(创建),PUT(创建或更新),DELETE(删除)来执行的.

编辑:感谢marxidad纠正每个动词应该映射的内容.