Restful API 关于批量删除的设计

以前参考过http://www.ruanyifeng.com/blog/2014/05/restful_api.html
自己分组或者添加ID范围？

单条和批量本质上是一样的啊，都是通过query string确定，只是单条有唯一标识符（比如id=1），批量就是一个范围（id>3&id<5）.

@tairan2006 restful 哦

我觉得 delete /users/1,2,3,4 (逗号可以做分隔符不？)

为了restful而restful这样好么...

“ 一般不建议在请求时添加消息体body”，我最后还是加了body，方便-_-#

users/:action?id[]=1&id[]=2&id[]=4

这样前端一组checkbox，后端一个array，方便。

不过很多库都不支持delete with body，lz慎重选择

如果批量删除数据的size比较小 ,并且是具体的数据,可以用3L的方式 而且有些restful框架支持将3L方式的path转换成数组。

Google 的做法似乎是 batch request

@belin520
@hcymk2
@arron

数据小的话确实可以通过query string来完成这事，但是我这边情况又有些特殊，首先id号不是自增的数字，而是mysql生成的uuid串，一个id号的长度就已经够长了，若是N个话，会出现url长度过长的问题吧。。。

@welsmann 求解决方法，主要是目前使用的各种http method都各司其职，不想专门针对这个case来做workaround，LZ有些许代码洁癖，额。。。

如果你用uuid作为id，又要这个批处理API的话。
我能想到的就是模仿http中的chuncked方式通信。约定总数或设置结束标记，前台分次发送，后台做缓存，结束标记时统一处理，返回结果。

顺便问一下：对表记录的id属性，为什么使用uuid？
我觉得是浪费，乱用uuid。

特殊情况还是用body吧，个人感觉uuid 很费。。。。没有必要。。。

也可以换一种思路，一个post + 一个delete
post: save workflow into table, like operate.o_id=12, have 12 uuid
delete: delete/o_id

btw, 一般遇到这种情况我会选择一种非restful的方法来实现，为了保证开发时效。

这篇文章设计了一个用put做soft delete的变通批量删除方法
http://www.l1ghtm4n.com/post/53259404576/patterns-for-rest-api-bulk-operations

我个人觉得REST批量删除还是尽量避免

jsonapi.org 撸主可以参考一下

@bsbgong
@lygmqkl
选择uuid还是自增id作为主键之前也做了很多比较，因为工作也不是专职DBA，看到uuid相对自增id还是有些优势的（非InnoDB引擎）,而且性能上差别也不是很大，有些人说这样导致url看起来很长很丑陋，我觉得这反而是个优势，像v2ex网站，大家可以看下每个帖子的url，其实还是能明显看出id号的增长情况的，这个有时候反倒是个隐患（比如商业分析），当然可能是自己想太多了，毕竟只是个小项目。说到这个问题，我倒是很想知道这两种主键策略，在一定的数据量下，mysql的性能和存储空间到底有多大的差别，这个网上也是个说纷纭，所以希望可以指点一二

@gevin 这篇文章恰好昨天再发这个帖子之前也看到了，归根到底还是一种变通的方式，不过确实如前面几位童鞋说，restful设计只是一种guideline，有些时候还是需要综合考虑和衡量

@jayn1985
我也是前段时间去查了下uuid，以前没怎么注意。
https://github.com/simongong/js-stackoverflow-highest-votes/blob/master/questions1-10/how-to-create-a-UUID-in-Javascript.md
一般程序里都没必要用uuid，你需要的只是一个uniq id。

这跟mysql的性能问题关系不大，主键的长短不影响索引的结构。当然最查找性能还是有点影响，毕竟不是自增量。而且最核心的匹配就是字符串比较，越长越慢呗。

至于商业隐患，这就看你们自己的衡量了。

@jayn1985 那就post啊。本来这种数据库更改删除操作基本都用post。 /users/delete