关于Restful 风格API设计问题

[一休00173]

针对Restful 风格的API设计，如果出现如下情况：

假定销售出库单数据表（saleout）字段如下：
单据编号、审核状态、是否关闭、是否删除等

业务单据数据表需要有“审核”、“关闭”、“编辑”、“删除（假删除）”功能，针对这些功能，需要分别对权限进行控制，由于这些操作都是针对于单表的更新操作，请问基于Restful风格的API如何设计？

另外，如果后台使用JSR303做数据校验，如下API是针对saleout数据表的更新操作：

saleouts/{code}

那么基于Resultful的API如下：

@PutMapping("/saleouts/{code}")
public JsonResult updateSaleoutById(@Pathvariable String code,@Validated Saleout saleout){
    // 更新操作...
}

如果这样设计就没有办法对code字段做参数校验，请问此时需要如何设计？

[LighBlade]

权限问题 1 方法上加注解（不同权限分类） 2 interceptor 判断方法名（不同权限对应不同的方法名前缀） 不能参数校验？ 啥意思？ @Min(value = 3, message = "年龄大于3岁") @RequestParam int age, 这个吗？

[一休00173]

引用 1 楼 LighBlade 的回复:

权限问题 1 方法上加注解（不同权限分类） 2 interceptor 判断方法名（不同权限对应不同的方法名前缀） 不能参数校验？ 啥意思？ @Min(value = 3, message = "年龄大于3岁") @RequestParam int age, 这个吗？

感谢您的回复，关于JSR303校验方法参数、权限问题我大致明白了，我自己尝试下。 另外关于“审核”、“关闭”、“编辑”、“删除（假删除）”功能，这些功能都属于更新操作，如果按照resultful风格设计API，那么API可能如下：

@PostMapping("/saleout/{code}")
public JsonResult check(@Pathvariable String code){
    // do something...
}
@PostMapping("/saleout/{code}")
public JsonResult close(@Pathvariable String code){
    // do something...
}
@PostMapping("/saleout/{code}")
public JsonResult edit(@Pathvariable String code,@RequestParam Saleout saleout){
    // do something...
}
@PostMapping("/saleout/{code}")
public JsonResult delete(@Pathvariable String code){
    // do something...
}

如果是这样的话，对于同样的请求类型URL就重复了，请问这种情况该如何处理？是在URL中加上操作类型吗？

[LighBlade]

销售出库单数据表（saleout）， 这名字起的。。。 ，资源是名词。 url设计 例如 saleout/audit, saleout/close, 正常的增删改用正常的rest设计风格（或者也做成sale/delete。。。) 解析 url的上下文，跟登录用户所拥有的（角色）权限对比， 就能判断了 以下是摘录： REST不是"rest"这个单词，而是几个单词缩写 -- REpresentational State Transfer 直接翻译：表现层状态转移，但这个翻译正常人根本看不懂，找到的一种最好理解的说法是，URL定位资源，用HTTP动词（GET,POST,DELETE,DETC）描述操作。 优点&缺点 优点是因为他对uri进行了限制，只用于定义资源。这样看起来比较容易理解。尤其是对简单的对象的增删改查，很好理解。 缺点是因为这种限制，导致设计uri变得复杂了。尤其是复杂的关系，操作，资源集合，硬性套用rest原则设计非常困难。在rest基础上的HATEOAS，返回的json里增加了相应的关系和url。这也同样带来问题。好处是对简单的关系，的确可以通过url进一步处理。但对复杂的关系和操作，HATEOAS并不能胜任描述。反而在单纯的数据中增加了一堆垃圾信息。

[一休00173]

引用 3 楼 LighBlade 的回复:

销售出库单数据表（saleout）， 这名字起的。。。 ，资源是名词。 url设计 例如 saleout/audit, saleout/close, 正常的增删改用正常的rest设计风格（或者也做成sale/delete。。。) 解析 url的上下文，跟登录用户所拥有的（角色）权限对比， 就能判断了 以下是摘录： REST不是"rest"这个单词，而是几个单词缩写 -- REpresentational State Transfer 直接翻译：表现层状态转移，但这个翻译正常人根本看不懂，找到的一种最好理解的说法是，URL定位资源，用HTTP动词（GET,POST,DELETE,DETC）描述操作。 优点&缺点 优点是因为他对uri进行了限制，只用于定义资源。这样看起来比较容易理解。尤其是对简单的对象的增删改查，很好理解。 缺点是因为这种限制，导致设计uri变得复杂了。尤其是复杂的关系，操作，资源集合，硬性套用rest原则设计非常困难。在rest基础上的HATEOAS，返回的json里增加了相应的关系和url。这也同样带来问题。好处是对简单的关系，的确可以通过url进一步处理。但对复杂的关系和操作，HATEOAS并不能胜任描述。反而在单纯的数据中增加了一堆垃圾信息。

明白了，谢谢您的解答。