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

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

这是一个创建于 3595 天前的主题，其中的信息可能已经有所发展或是发生改变。

以前在上学的时候留下个场馆预订的坑项目，毕业后师弟接手，老师让给加上手机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}

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

orderid

userid

orderstate

5 条回复 • 2015-02-27 09:33:12 +08:00

Dongdong36

2015-02-26 21:41:18 +08:00

个人感觉，尽量保持API的简洁比较好，一个API只做一件事情，保证逻辑代码的清晰，简洁

权限控制，这个应该是中间件的工作，判断用户是否具有使用API的权限

Dongdong36

2015-02-26 21:41:55 +08:00

以上个人感觉，如有不当请路过的大神指正，Thx

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 接口时的习惯，也请路过大牛指正。

feelapi

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

我觉得是这样，不需要增加新的api和uri, API的每次调用都需要认证的，权限控制在服务器端做细化就可以了。
http://limboy.me/tech/2010/11/14/rest.html
http://www.weiguda.com/blog/22/

heaton_nobu

2015-02-27 09:33:12 +08:00

之前我也问过类似的问题，很多大神给的答案是将用户对应的权限放入缓存中
url中不用包含{userID}，因为操作的肯定是当前登录用户，用户的标识放在cookie中就可以了