RESTful服务中的非CRUD操作
将非CRUD操作添加到RESTful服务的“RESTful”方式是什么？ 说我有一个服务，允许CRUD访问这样的logging：
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并且为新颜色包含一个POSTvariables。
但是，假设我想购买一辆汽车，而且这个操作比简单地更新“用户”logging的“拥有汽车”属性更为复杂。 简单地做一些像POST /api/car/123/purchase这样的“RESTful”，其中“purchase”本质上是一个方法名称？ 还是应该使用自定义的HTTP动词，比如PURCHASE而不是POST ？
还是非CRUD操作完全超出了REST的范围？
将购买考虑为RESTful字典中的业务实体或资源 。 这就是说，进行购买实际上是在创造一种新的资源。 所以：
POST /api/purchase
会发出一个新的命令。 详细信息（用户，汽车等）应该通过发送到这个地址的内容中的id（或者URI）来引用。
订购汽车并不仅仅是数据库中的一个简单的INSERT。 实际上，REST并不是将你的数据库表暴露为CRUD操作。 从逻辑的angular度来看，您正在创build一个订单（购买），但是服务器端可以自由地按照需要执行多个处理步骤。
甚至可以进一步滥用HTTP协议。 使用Location标题返回到新创build订单的链接，仔细selectHTTP响应代码以通知用户有关问题（服务器端或客户端）等
按照我的理解，RESTful的方式是，你不需要新的HTTP动词，有一个名词的地方，这将意味着你需要做什么。
买车？ 那不是那个
POST /api/order
你真正在做的是创build一个订单。 所以添加另一个订单和发布资源，并在订单过程中。
考虑资源而不是方法调用。
要完成订单，你可能会POST / API /命令//完成或类似的东西。
我觉得REST API不仅仅是提供语义，还有更多的帮助。 所以不能仅仅因为一些调用在RPC操作风格上更有意义就selectRPC风格。 例子是谷歌地图APIfind两个地方之间的方向。 看起来像这样： http : //maps.googleapis.com/maps/api/directions/json? origin=Jakkur&destination= Hebbal
他们可以称它为“findDirections”（动词），并把它当作一个操作。 相反，他们把“方向”（名词）作为一种资源，并将方向作为查询的方向资源（尽pipe内部不存在称为方向的真实资源，并且可以由业务逻辑来实现，以基于参数来查找方向）。
