Restful API 关于批量删除的设计

2014-12-16 10:45:39 +08:00
 jayn1985
业余时间自己在搞一个小项目,后端使用Restful API设计,针对单一实体的操作这个很容易理解和设计,批量操作的话增改查也都有对应的处理方法,但是目前只有针对批量删除我这边有点卡壳,看了一些Restful APi设计的文章,里面提到针对DELETE方法,一般不建议在请求时添加消息体body,那么针对批量删除的场景大家都是怎么设计的呢?有没有什么业界通用的方法呢?
21995 次点击
所在节点    程序员
20 条回复
paradislover
2014-12-16 13:08:40 +08:00
以前参考过http://www.ruanyifeng.com/blog/2014/05/restful_api.html
自己分组或者添加ID范围?
tairan2006
2014-12-16 13:11:47 +08:00
单条和批量本质上是一样的啊,都是通过query string确定,只是单条有唯一标识符(比如id=1),批量就是一个范围(id>3&id<5).
belin520
2014-12-16 13:17:57 +08:00
@tairan2006 restful 哦

我觉得 delete /users/1,2,3,4 (逗号可以做分隔符不?)
welsmann
2014-12-16 13:20:41 +08:00
为了restful而restful这样好么...
xudshen
2014-12-16 13:25:02 +08:00
“ 一般不建议在请求时添加消息体body”,我最后还是加了body,方便-_-#
arron
2014-12-16 13:25:47 +08:00
users/:action?id[]=1&id[]=2&id[]=4

这样前端一组checkbox,后端一个array,方便。
xudshen
2014-12-16 13:30:14 +08:00
不过很多库都不支持delete with body,lz慎重选择
hcymk2
2014-12-16 13:35:44 +08:00
如果批量删除数据的size比较小 ,并且是具体的数据,可以用3L的方式 而且有些restful框架支持将3L方式的path转换成数组。
GhostFlying
2014-12-16 13:37:40 +08:00
Google 的做法似乎是 batch request
jayn1985
2014-12-16 15:06:25 +08:00
@belin520
@hcymk2
@arron

数据小的话确实可以通过query string来完成这事,但是我这边情况又有些特殊,首先id号不是自增的数字,而是mysql生成的uuid串,一个id号的长度就已经够长了,若是N个话,会出现url长度过长的问题吧。。。
jayn1985
2014-12-16 15:09:38 +08:00
@welsmann 求解决方法,主要是目前使用的各种http method都各司其职,不想专门针对这个case来做workaround,LZ有些许代码洁癖,额。。。
bsbgong
2014-12-16 16:07:26 +08:00
如果你用uuid作为id,又要这个批处理API的话。
我能想到的就是模仿http中的chuncked方式通信。约定总数或设置结束标记,前台分次发送,后台做缓存,结束标记时统一处理,返回结果。

顺便问一下:对表记录的id属性,为什么使用uuid?
我觉得是浪费,乱用uuid。
lygmqkl
2014-12-16 17:35:14 +08:00
特殊情况还是用body吧,个人感觉uuid 很费。。。。没有必要。。。

也可以换一种思路,一个post + 一个delete
post: save workflow into table, like operate.o_id=12, have 12 uuid
delete: delete/o_id
lygmqkl
2014-12-16 17:35:58 +08:00
btw, 一般遇到这种情况我会选择一种非restful的方法来实现,为了保证开发时效。
gevin
2014-12-16 21:51:44 +08:00
这篇文章设计了一个用put做soft delete的变通批量删除方法
http://www.l1ghtm4n.com/post/53259404576/patterns-for-rest-api-bulk-operations

我个人觉得REST批量删除还是尽量避免
ryanking8215
2014-12-17 07:08:38 +08:00
jsonapi.org 撸主可以参考一下
jayn1985
2014-12-17 10:13:02 +08:00
@bsbgong
@lygmqkl
选择uuid还是自增id作为主键之前也做了很多比较,因为工作也不是专职DBA,看到uuid相对自增id还是有些优势的(非InnoDB引擎),而且性能上差别也不是很大,有些人说这样导致url看起来很长很丑陋,我觉得这反而是个优势,像v2ex网站,大家可以看下每个帖子的url,其实还是能明显看出id号的增长情况的,这个有时候反倒是个隐患(比如商业分析),当然可能是自己想太多了,毕竟只是个小项目。说到这个问题,我倒是很想知道这两种主键策略,在一定的数据量下,mysql的性能和存储空间到底有多大的差别,这个网上也是个说纷纭,所以希望可以指点一二
jayn1985
2014-12-17 10:15:59 +08:00
@gevin 这篇文章恰好昨天再发这个帖子之前也看到了,归根到底还是一种变通的方式,不过确实如前面几位童鞋说,restful设计只是一种guideline,有些时候还是需要综合考虑和衡量
bsbgong
2014-12-17 10:46:02 +08:00
@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的性能问题关系不大,主键的长短不影响索引的结构。当然最查找性能还是有点影响,毕竟不是自增量。而且最核心的匹配就是字符串比较,越长越慢呗。

至于商业隐患,这就看你们自己的衡量了。
arron
2014-12-17 11:46:05 +08:00
@jayn1985 那就post啊。本来这种数据库更改删除操作基本都用post。 /users/delete

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/154258

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX