Restful API 关于批量删除的设计

V2EX = way to explore

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

现在注册

已注册用户请登录

• 请不要在回答技术问题时复制粘贴 AI 生成的内容

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

业余时间自己在搞一个小项目，后端使用Restful API设计，针对单一实体的操作这个很容易理解和设计，批量操作的话增改查也都有对应的处理方法，但是目前只有针对批量删除我这边有点卡壳，看了一些Restful APi设计的文章，里面提到针对DELETE方法，一般不建议在请求时添加消息体body，那么针对批量删除的场景大家都是怎么设计的呢？有没有什么业界通用的方法呢？

RESTful

批量

API

20 条回复 • 2014-12-17 11:46:05 +08:00

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 via iPhone

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