举例： 前提：系统有三方 1. 运营方、2. 店铺（B端用户）3. 用户（C端用户） 用户进行下单操作 接口定义： 查询订单详情接口： To B: /sellers/:sellerId/orders/:orderId To C: /buyers/:buyerId/orders/:orderId 问题： 对于订单的这样的实体好解释，订单可以是用户的也可以是属于店铺的。如果只有运营平台和买方，运营平台查询一个商品信息可以是/items/:itemId，用户查看也是/items/:itemId。查询出来的信息，应该是运营平台要多一些，类似商品的销售提成这样的信息。如何定义RESTful路由？
@stonephp 对，对外肯定是两个接口，类似资源定位的方式去体现，但是不知道具体该如何定位。因为类似商品资源不属于用户，如何去定义这部分资源，直接 /items/:itemId 就这样取获取信息。那如果管理员获取商品信息，也是/items/:itemId，这样就没办法在路由上进行区分了。
@yszou 代码层面 经过路由层之后 应该是拦截器，在拦截器中解析用户信息，根据不同的权限设定返回值范围。拦截器过后可以进入controller，从这一步开始 就应该可以逻辑重用了，如果有特殊的地方，可以进行权限判断。但是不知道我举的例子该如何去定义路由。。
可以是同一个 url，根据权限返回不同数据 也可以在 url 上区分权限 也可以把权限参数放在 query 里
restful 对于权限的规范没有太多条条框框
- 可以根据用户的权限(或者用户的角色)来返回数据. RESTful 也有用户认证的标准, token. token 代表了一个实体的权限(角色). 判断 token 是哪一类的用户, 则返回对应的数据即可. 这样的话你上面定义的 url 是没有问题的.
- 可以定义不一样的 url 来区分不同的数据. 及1. 运营方可以是一个 url. 2. 店铺可以是一个 url.
@anziguoer 是的如果把你的两个观点捏合在一起我觉得是完美的，如果只是根据用户角色来返回数据会存在这样的一个问题，就是B端用户在C端登录并请求数据时返回的数据依然是B端能看到的所有数据，这显然并不是我期望的。
针对不同的系统 (Client)，资源抽象 (Model) 也应该不同。 例如用户与运营平台对商品关注点是不一样的， 所以抽象 Model 的时候需要针对 Client 抽象出符合各自需要的 Model， 既然 Model 不同了，那就没必要共用同一个 url 了; 在 restful api 设计上可以在 baseurl 加入二级路由区分 client， 例如: http://xxxx.com /a + /items/:itemId , http://xxxx.com /c + /items/:itemId, 如果 api 有 version controller,也可以加在baseurl 区分， 例如： http://xxxx.com/a/v1 + /items/:itemId
