Restful 的 API 的设计时的权限控制（资源抽象？）问题

以前在上学的时候留下个场馆预订的坑项目，毕业后师弟接手，老师让给加上手机APP。然后就想给改成RestfulAPI的，顺便把页面也重构了。奆奆们指导。
在设计API的时候有这个情况，当时这么设计一个订单Order

class Order {
        private String orderID;
       private String usreID;
       private String fieldsID;
       ...
       private OrderState orderState;
       ...
       ...
    }

其中 orderState代表订单状态,姑且有(为确认，已确认，已消费，过期）等
对于用户而言是无法修改订单状态的，可以修改预订内容，例如这么设计用户可用的，

新建订单 POST /api/orders/{userID}
修改 PUT/PATCH /api/orders/{userID}/{orderID}
获取 GET /api/orders/{userID}/{orderID}
删除 DELETE /api/orders/{userID}/{orderID}

对于场馆方面，前台需要在用户来消费时改变订单状态,即只能更改客户的一个字段。那这个API怎么设计？ 是说同样使用

修改  PUT/PATCH /api/orders/{userID}/{orderID}

然后在代码里用逻辑进行判断。 还是说，增加新的API

PATCH /api/orders/state/{orderID}

大家一般是怎么做这种权限控制的呢？

special

2015-02-26 23:52:17 +08:00

为什么要把 userID 加进 API 的 URL 呢？新建、修改订单的 API，userID 都不是当前登录的用户么？

另外，对于「消费」这个相对来说独立的动作，应该分配一个独立的 API 接口，这个 API 接口集中处理「消费」一系列的逻辑。

```
PUT/PATCH /api/orders/{orderID}/pay
```

修改订单某些简单属性，例如联系人电话什么的，可以用

```
修改 PUT/PATCH /api/orders/{orderID}
```

当然，这个只是小的在 Rails 设计 API 接口时的习惯，也请路过大牛指正。