V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
jayn1985
V2EX  ›  程序员

Restful API 关于批量删除的设计

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

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

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

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

    顺便问一下:对表记录的id属性,为什么使用uuid?
    我觉得是浪费,乱用uuid。
    lygmqkl
        13
    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
        14
    lygmqkl  
       2014-12-16 17:35:58 +08:00
    btw, 一般遇到这种情况我会选择一种非restful的方法来实现,为了保证开发时效。
    gevin
        15
    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
        16
    ryanking8215  
       2014-12-17 07:08:38 +08:00 via iPhone
    jsonapi.org 撸主可以参考一下
    jayn1985
        17
    jayn1985  
    OP
       2014-12-17 10:13:02 +08:00
    @bsbgong
    @lygmqkl
    选择uuid还是自增id作为主键之前也做了很多比较,因为工作也不是专职DBA,看到uuid相对自增id还是有些优势的(非InnoDB引擎),而且性能上差别也不是很大,有些人说这样导致url看起来很长很丑陋,我觉得这反而是个优势,像v2ex网站,大家可以看下每个帖子的url,其实还是能明显看出id号的增长情况的,这个有时候反倒是个隐患(比如商业分析),当然可能是自己想太多了,毕竟只是个小项目。说到这个问题,我倒是很想知道这两种主键策略,在一定的数据量下,mysql的性能和存储空间到底有多大的差别,这个网上也是个说纷纭,所以希望可以指点一二
    jayn1985
        18
    jayn1985  
    OP
       2014-12-17 10:15:59 +08:00
    @gevin 这篇文章恰好昨天再发这个帖子之前也看到了,归根到底还是一种变通的方式,不过确实如前面几位童鞋说,restful设计只是一种guideline,有些时候还是需要综合考虑和衡量
    bsbgong
        19
    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
        20
    arron  
       2014-12-17 11:46:05 +08:00
    @jayn1985 那就post啊。本来这种数据库更改删除操作基本都用post。 /users/delete
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1754 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 25ms · UTC 16:41 · PVG 00:41 · LAX 08:41 · JFK 11:41
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.