RESTful服务中的非CRUD操作

将非CRUD操作添加到RESTful服务的“ RESTful”方式是什么？假设我有一项服务，允许CRUD访问以下记录：

GET /api/car/123           <- Returns information for the Car object with ID 123
POST /api/car              <- Creates a new car (with properties in the request)
PUT /api/car/123           <- Updates car 123 (with properties in the request)
DELETE /api/car/123        <- Deletes car 123    
POST /api/car/123/wheel/   <- Creates a wheel and associates it to car 123

如果要更改汽车的颜色，则只需POST /api/car/123添加新颜色的POST变量即可。

但是，假设我要购买汽车，并且该操作比简单地更新“用户”记录的“自有汽车”属性要复杂得多。简单地做类似RESTful的事情POST /api/car/123/purchase，其中“购买”本质上是一个方法名称？还是应该使用自定义HTTP动词，例如PURCHASE代替POST？

还是非CRUD操作完全超出REST的范围？

考虑将购买作为业务实体或RESTful词典中的资源。话虽如此，购买实际上是在创造新的资源。所以：

POST /api/purchase

将下新订单。详细信息（用户，汽车等）应通过发送到该地址的内容中的id（或URI）进行引用。

预订汽车并不只是数据库中的简单INSERT。实际上，REST与将数据库表公开为CRUD操作无关。从逻辑的角度来看，您正在创建订单（购买），但是服务器端可以根据需要自由执行任意数量的处理步骤。

您甚至可以进一步滥用HTTP协议。使用Location标头将链接返回到新创建的订单，仔细选择HTTP响应代码以通知用户有关问题（服务器端或客户端）等。

据我了解，REST式的方式是您不需要新的HTTP动词，某处有一个名词表示您需要做的事情。

买车？那不是吗

POST /api/order

您真正要做的是创建订单。因此，为订单添加另一个资源，然后在订单过程中过帐并放置在那里。

考虑资源而不是方法调用。

要最终确定订单，您可能需要POST / api / order // complete或类似的命令。

我觉得REST API不仅提供语义，还提供了更多帮助。因此，不能仅仅因为某些调用在RPC操作风格中似乎更有意义而选择RPC风格。示例是Google Maps API，用于查找两个地方之间的路线。看起来像这样：http : //maps.googleapis.com/maps/api/directions/json? origin=Jakkur&destination= Hebbal

他们可以将其称为“ findDirections”（动词）并将其视为一个操作。相反，他们将“方向”（名词）作为资源，并将查找方向作为对方向资源的查询（尽管在内部可能没有称为方向的真实资源，并且可以由业务逻辑实现以基于参数查找方向）。