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

开发 API 的时候 http method 应该使用 PUT、PATCH、DELETE 等协议还得直接用 GET、POST

  •  1
     
  •   Inzufu ·
    Lilac-milena · 63 天前 via Android · 8559 次点击
    这是一个创建于 63 天前的主题,其中的信息可能已经有所发展或是发生改变。
    如题,
    感觉前三者好像更规范些,不过好像很少见有用除 GET 和 POST 外协议的接口。
    142 条回复    2024-03-28 22:03:05 +08:00
    1  2  
    seers
        1
    seers  
       63 天前 via Android   ❤️ 3
    我只说一点,大部分漏扫等保公司只会允许 GET/POST ,然后客户只会让你整改,当然自己玩随便
    cxsz
        2
    cxsz  
       63 天前   ❤️ 1
    我自己写的基本都是 get ,用起来方便,浏览器输入一下就行,公司规定是统一 post
    flyqie
        3
    flyqie  
       63 天前   ❤️ 1
    每隔一段时间就会出现这样的讨论,建议先左上搜索一下

    看个人喜好和环境要求,我个人是 200 + post ,http_code != 200 问题肯定都是基础设施,跟我没关系。。
    0o0O0o0O0o
        4
    0o0O0o0O0o  
       63 天前   ❤️ 8
    你可以看看他们争得有多激烈:

    /t/860356
    /t/830030
    /t/693907
    /t/959602
    /t/340607

    与之齐名的还有 https://www.v2ex.com/t/1023997#r_14451382
    drymonfidelia
        5
    drymonfidelia  
       63 天前   ❤️ 1
    @flyqie
    @0o0O0o0O0o 还有这个 /t/899875
    OutOfMemoryError
        6
    OutOfMemoryError  
       63 天前   ❤️ 1
    @seers #1 +1 我们之前遇到一个“安全检测”就是这种要求,只好做了个变通方案,前端传 Header 到 nginx ,然后 nginx 处理一下发到后端
    Inzufu
        7
    Inzufu  
    OP
       63 天前 via Android
    @flyqie 我一般也是 POST 用的多一些,状态码就是
    200 、401 、403 、404 ,其他的状态码还真没用过。
    Inzufu
        8
    Inzufu  
    OP
       63 天前 via Android
    @cxsz GET 请求一般直接把参数放在 url 里,个人总感觉不是很安全。
    Inzufu
        9
    Inzufu  
    OP
       63 天前 via Android
    @seers @OutOfMemoryError 那看来还是用 GET POST 比较好,我个人感觉 PUT 、PATCH 、DELETE 这三个 methods 其实完全可以用 POST 代替。
    infun
        10
    infun  
       63 天前   ❤️ 1
    臆想的规范,现实世界比臆想世界复杂的多,抽象出来的方法很多时候都是脱裤子放屁
    个人支持 get post 全包
    winterpotato
        11
    winterpotato  
       63 天前
    🤣我们公司就不一样了,我们公司全部 get 数据通过 headers 发🤡

    (开个玩笑)
    当然遵循 restful 语义了
    securityCoding
        12
    securityCoding  
       63 天前 via Android
    谁用 restful 我会暗自骂他傻 233
    agagega
        13
    agagega  
       63 天前
    即使环境不能使用 PUT/PATCH/DELETE ,用 POST 模拟也是好的,或者就用 POST 表达发起某个事务的含义也完全没问题。怕的就是一股脑全用 GET ,创建订单也来个 GET ,这就无可救药了。
    luodan
        14
    luodan  
       63 天前
    小白请教那些全用 GET 的同学一个问题,用 GET 不是大家都看得一清二楚了吗?
    Kumo31
        15
    Kumo31  
       63 天前
    都用,RESTful API ,当然 RESTful API 的表达能力有缺陷,难以满足复杂业务场景,还需要结合 Google 的 Custom methods: https://google.aip.dev/136
    icy37785
        16
    icy37785  
       63 天前 via iPhone   ❤️ 13
    虽然别人问我接口怎么定义,我推荐 RESTful ,自己的项目只用 get 、post ,甚至看到 restful 还会发笑。
    siweipancc
        17
    siweipancc  
       63 天前 via iPhone
    理论中:新建记录 post 返回 201 重定向到数据。
    实际操作:返回 200 加个 ok 状态码。
    问就是流程越简单 bug 越少。
    leo72638
        18
    leo72638  
       63 天前
    @luodan #14 要安全肯定要 https 。你只用 http 的话,用什么请求方式没本质区别,懂拦截请求的人不会不懂看 body 里的数据
    raycool
        19
    raycool  
       63 天前
    post 一把梭吧
    zeromake
        20
    zeromake  
       63 天前 via Android
    我之前也想各种 put ,delete 用起来,然后客户端一对接说客户端框架封死了只能用 get ,post😂
    maymay5
        21
    maymay5  
       63 天前
    post 走全部
    lujiaxing
        22
    lujiaxing  
       63 天前
    视情况.
    如果是系统内互相调用, 一般就是 get/post. 没啥必要搞什么 put delete...
    如果是开放 API, 而且本身也比较简单 (例如只是开放个 WEB 接口给三方读写数据之类的), 可以用 RESTful API.

    我个人是不喜欢 RESTful 这个风格的. 太简陋了, 对于一些复杂的业务接口来说, 要么把 URL 搞得极其抽象
    (如: /api/v3/userrelationshipinorganization/7333/8964) 要么把接口拆散拆得跟被爆破了一样, 然后让前端做整合层.

    无论哪种其实都很恶心.
    IdJoel
        23
    IdJoel  
       63 天前
    DELETE PUT 多好用,要不 URL 整那老长多难受
    对接的开发一眼就能看出来接口是干啥的,多直观啊?
    wangkun025
        24
    wangkun025  
       63 天前 via Android
    我选择遵守 restful
    caomu
        25
    caomu  
       63 天前 via Android
    @seers
    @OutOfMemoryError 这啥道理?
    cmdOptionKana
        26
    cmdOptionKana  
       63 天前
    RESTful 是自找麻烦
    lff0305
        27
    lff0305  
       63 天前
    以前做项目见过的:

    客户有奇葩的防火墙/负载均衡,对于
    1. 非 Get Post 请求,高峰期不能保证 QOS ,要对 Get Post 让路
    2. 非 2XX 返回值,会把 response 封装成类似 upstream error:<原始的 body> 而且可能 body 还会被截断

    所以为了适应客户把项目做下去只能全部 GetPost ,用 200 返回,再把错误信息放在 Body 里面
    cmdOptionKana
        28
    cmdOptionKana  
       63 天前
    RESTful 就是非常典型的学院派风格,理论上很优雅,很美,但实践中弊大于利,碍手碍脚。
    afxcn
        29
    afxcn  
       63 天前
    我们就用 RESTful 风格的,国内国外的项目也没遇到什么问题。
    aragakiyuii
        30
    aragakiyuii  
       63 天前 via Android   ❤️ 30
    MrDarnell
        31
    MrDarnell  
       63 天前   ❤️ 6
    还是要走 restful 规范,现在很多公司规定 post 其实是一种负责人能力低下的表现,但碍于自尊心,拒绝承认
    layxy
        32
    layxy  
       63 天前
    get,post,put,delete 四个都用,之前遇到过前端会吐槽说分不清接口,path 都一样容易调错
    IvanLi127
        33
    IvanLi127  
       63 天前
    反正我们严格遵守 RESTful ,等保和安全都过得去。我感觉这些请求方法都挺常见的
    wangtian2020
        34
    wangtian2020  
       63 天前
    都可以,市面上常见的两种接口风格
    proxychains
        35
    proxychains  
       63 天前
    GET 查询
    POST 新增
    hash
        36
    hash  
       63 天前
    就像一楼说的,POST 一把梭是有他的原因的,但我仍然认为 POST 一把梭是傻逼
    毕竟没有任何一个人一辈子只做政府外包
    jonsmith
        37
    jonsmith  
       63 天前
    我用 get 和 post ,请求数据用 get 、更新用 post ,也见过全部用 post 的,但是全部 get 应该做不到。
    proxychains
        38
    proxychains  
       63 天前   ❤️ 1
    GET 查询
    POST 新增
    PUT 修改
    DELETE 删除
    bitmin
        39
    bitmin  
       63 天前
    大部分接口都很简单,省得想名字,/、/{id} GET POST DELETE PUT PATCH 对应增删改查多简单

    复杂接口另说,当然是随机应变

    还好我们接口都是自己用,除了老板没人指手划脚
    me1onsoda
        40
    me1onsoda  
       63 天前
    现实的情况很复杂,一个新增的过程可能也有查询删除修改
    Dlin
        41
    Dlin  
       63 天前
    有规范大家不使用,所有大家才会觉得碍手碍脚。
    cnevil
        42
    cnevil  
       63 天前
    http 标准中 delete 方法也不是给你这样用的吧
    我觉得遵循国际标准比那什么 restful api 标准理由要充分的多。。
    jydeng
        43
    jydeng  
       63 天前
    我们用 gql
    shuax
        44
    shuax  
       63 天前
    老夫只会 post json 一把梭。
    wanguorui123
        45
    wanguorui123  
       63 天前
    JAVA 里面 POST 最简单和通用,GET 简单的查询可以用用
    shyangs
        47
    shyangs  
       63 天前   ❤️ 2
    @MrDarnell

    RESTful 是風格(style),不是規範/標準(standard).

    標準有標準文件,比如 JSON 的文件 ECMA-404 是由 ECMA 編寫.

    RESTful 是一份 2000 年的博士論文出來的風格,早就過時了,這位博士生可能連 XML(1998), JSON (2001) 都沒寫過,只好什麼都往網址上塞,這種過時風格被追捧太滑稽了. 連 JSON-RPC (2005) 都比 RESTful (2000) 新穎.
    Van426326
        48
    Van426326  
       63 天前
    一楼说的对 我也不想改啊 等保过不了有啥办法
    echo0x000001
        49
    echo0x000001  
       63 天前
    很多人觉得 restful 不好用是因为没有工具,django 的 DRF 框架用起来不用太爽,节省很多代码。
    ShinichiYao
        50
    ShinichiYao  
       63 天前
    get 也别要了,post 一把梭
    ben666
        51
    ben666  
       63 天前
    get post put delete 都是常用的
    本来开源网络性能测试仪 dperf 只支持 get ,有人提 issue 希望支持各种 method
    https://github.com/baidu/dperf/
    flyqie
        52
    flyqie  
       63 天前 via Android
    @MrDarnell #31

    `负责人能力低下`

    醒醒,你是乙方。。
    huangzongzhuan
        53
    huangzongzhuan  
       63 天前
    get -> 读
    post -> 写

    完事
    z1154505909
        54
    z1154505909  
       63 天前
    我特么要喷一个腾讯,文档写的 get,例子也是 get,我用 get 请求返回我访问未知的 url,垃圾腾讯
    DOLLOR
        55
    DOLLOR  
       63 天前 via Android
    @proxychains
    login 应该用哪个呢?
    qa2080639
        56
    qa2080639  
       63 天前
    get 传值有类型问题 null false true 不好表示,所以我全用 post 传 json 一把梭 别人还在研究怎么定义接口我已经下班了
    Laobai
        57
    Laobai  
       63 天前
    只能 post 一把梭,否则扫描过不了
    TomeVictor
        58
    TomeVictor  
       63 天前
    查询用 get ,其他 post 一把嗦,运维淡疼在网关把其他都拦掉了。
    qbmiller
        59
    qbmiller  
       63 天前
    2B 项目。老老实实 get post
    zxkxhnqwe123
        60
    zxkxhnqwe123  
       63 天前   ❤️ 1
    原来 RESTful
    一段时间 GET POST
    现在 POST
    thinkershare
        61
    thinkershare  
       63 天前
    这种重复提问,管理员应该禁止掉。
    Torpedo
        62
    Torpedo  
       63 天前
    restful 不是一个好风格。因为实践里,我见到的每个自称 restful 风格的 api 都有不同。特别是一些模糊行为
    MrKrabs
        63
    MrKrabs  
       63 天前
    RESTful=野鸡
    zw1one
        64
    zw1one  
       63 天前   ❤️ 1
    post 一把梭真的很香,代码也很健壮,也很方便复制粘贴。省下来的时间可以摸鱼,活动下颈椎,让你身体精神保持健康。
    julyclyde
        65
    julyclyde  
       63 天前
    @Inzufu PUT/PATCH/DELETE 的 URI 是一个目标对象; POST 的 URI 是一个 handler ,参数是一个对象
    daiv
        66
    daiv  
       63 天前
    @raycool @maymay5 @shuax @ShinichiYao @Laobai @zxkxhnqwe123 @zw1one 如果全部用 Post, 那么路径如何设计更合理?

    创建( Create ): POST /api/v1/user/create
    更新( Update ): POST /api/v1/user/update
    读取( Read ): POST /api/v1/user/read
    列表( List ): POST /api/v1/user/list
    操作( Operate ): POST /api/v1/users/operate (Delete, HardDelete, Restore, Copy 等等...)

    各位大佬有什么建议吗? 这样是否合理.
    leaflxh
        67
    leaflxh  
       63 天前
    无非在于错误在哪处理

    .then(res=>{ res.code === 200})
    还是
    .catch(err)
    olaloong
        68
    olaloong  
       63 天前
    稍微复杂点的业务用 RESTful 都是一团糟,毕竟一次调用里操作的可不止一个资源。硬套 RESTful 的话,要么按资源拆分请求,那复杂均衡、事物就糟了,要么在一个资源操作里隐性操作其他资源,时间一长就变成屎代码。
    见过几个项目设计之初想用 RESTful ,最后都变成了特色 RESTful 的杂交项目。
    flyqie
        69
    flyqie  
       63 天前 via Android
    @leaflxh #67

    个人觉得 post+200 一把梭主要是为了分层,走到 catch 是基础设施问题,其他的是业务问题。
    flyqie
        70
    flyqie  
       63 天前 via Android
    @flyqie #69
    而且还能避免很多奇怪问题
    crackidz
        71
    crackidz  
       63 天前
    取决于你客户端开发的水平😂
    JenJieJu
        72
    JenJieJu  
       63 天前
    graphql ,前端自己撸
    giiiiiithub
        73
    giiiiiithub  
       63 天前
    必须是考虑语义、Safe 和 Idempotent ,这些性质和 restful 无关,纯纯 rfc2616 中定义的啊。。。
    chendy
        74
    chendy  
       63 天前
    全部 POST ,因为要兼容 ie ,put 之类的不敢用,get 有时候缓存了全麻
    全部 200 ,因为对接的前端喜欢,反正写起来都一样
    momo24672
        75
    momo24672  
       63 天前
    GET 读
    POST 创建
    DELETE 删除
    PATCH 更新

    POST 一把梭的全是 SB/垃圾
    lesismal
        76
    lesismal  
       63 天前
    > POST 一把梭的全是 SB/垃圾

    @momo24672 不选择 Restful 的人会越来越多, 注意, 我说的是"不选择", 而不是"放弃", 因为 Restful 本来就不是必选项. 另外, 别太自信了
    flyqie
        77
    flyqie  
       63 天前 via Android
    @momo24672 #75

    我记得 bilibili 部分项目貌似最后就是 post 一把梭。
    proxychains
        78
    proxychains  
       63 天前
    @DOLLOR #55
    GET
    /login/username/md5(pwd)
    picone
        79
    picone  
       63 天前
    默认情况下,NginX 会认为 POST 等是非幂等请求,不会进行重试,POST 一把梭用户怎么解决这个问题
    wjfz
        80
    wjfz  
       63 天前
    非要 post 也行,像#66 那种也还算清晰。
    关键是错误处理,用 200 状态+错误码,前后端约定几十个错误码是一件及其傻逼的事情。
    WashFreshFresh
        81
    WashFreshFresh  
       63 天前
    @picone 用户会解决 手动狗头
    hxysnail
        82
    hxysnail  
       63 天前   ❤️ 2
    大家是不是对 Restful 有什么误解,Restful 多出来好几种 method ,是 GET/POST 的超集,不存在能力比 GET/POST 更弱吧?

    我维护的项目,采用 Restful 协议,迭代了好多年,没发现有什么坑啊

    比如,一个资源普通的增删改,能有什么问题?

    POST /Datas # 新增
    GET /Datas/{id} # 查询
    PUT /Datas/{id} # 修改(整体替换)
    PUT /Datas/{id} # 修改(部分更新)
    DELETE /Datas/{id} # 删除

    对于特殊的业务逻辑,我们约定好一个在某个资源上做的一个动作,范式如下:
    POST /some/resource/path/_action

    举个例子,我们想让数据支持软删除:
    POST /Datas/{id}/_markDeleted # 软删除(打标记但数据不删)

    再举个例子,搜索数据集合,Body 传一个 Filter (比如 Name 符合某个正则表达式):
    POST /Datas/_search

    {
    "Filter": {
    "Name": {
    "$regex": "abc"
    }
    }
    }

    最后一个例子,某条数据记录想发一条通知出来:
    POST /Datas/{id}/_notify

    迭代了这么多年,没发现有什么所谓的业务逻辑套不进去的问题啊。

    还看到一个说法说,Restful 需要写好多个接口,然后再让前端来整合?这不是典型的接口 [粒度] 问题嘛……

    站在后端的角度,接口粒度合理拆细是可以,难不成来个场景你加个接口刷一刷存在感吗?别人我不知道,我对手下的后端的要求就是合理地细,让前端可以灵活组合完成特定、个性化的业务场景。

    站在项目统筹管理的角度,如有某种组合很常用,你让前端自己一遍遍地去拼接也不合理吧?这个时候不就提供一种粒度更粗,但更固化的接口出来吗?这样双方不都得到满足吗?同样别人我不知道,我对手下的前端的要求,就是接口不合理,需要不断重复组合的逻辑,就要反馈给后端。然后一起消除重复性。

    总结:①后端接口粒度在合理的前提下,尽量细;②对于常用组合,再封装更固化和个性化的粗粒度接口。

    还有一个问题,说前端框架封死了只能 GET/POST……挖槽,前端垃圾关你啥事?关 Restful 啥事?能 diss 他就 diss 他,不能 diss 他的就捏着鼻子接受吧。

    还有人提到,说客户公司只允许用 GET/POST ,怎么说呢?都做乙方了,当然没办法了,甲方说啥就是啥……但这是你还是有办法在 POST 方法的基础上,自行定义一套给 Restful 类似的协议,无法是把原本用 Method 来表达的信息搬到 body 里而已。举个例子:

    POST /Datas/{id}

    {
    "Action": "UPDATE",
    "Data": ……
    }


    因此,重点不是 Restful or GET/POST ,重点是接口要满足一套统一而且规范的范式。

    我同意有人提到说 GET 、POST 是负责人不负责任的做法。就 POST 请求,然后 path 爱怎么定就怎么定,数据爱怎么传就怎么传,最终一定是座代码屎山。举个例子,我合作过的项目,就纯 POST 的,但接口五花八门。同一种数据,不同接口返回的格式有些字段名还不太一样,一不留神就被坑到。这就是垃圾。被坑的次数多了,别人就会抗拒跟他合作。

    据我的观察,绝大部分程序员,特别是外包根本就没有驾驭抽象范式的能力。没能力也就算了,不少人还喜欢浮于表面,夸夸其谈。说到底,“无规则不成方圆”,这么简单的道理,我们几千年前的老祖宗都懂。但不少所谓的新时代开发工程师,还在重复着开发一个垃圾接口,再写一份垃圾文档来描述这个垃圾接口的死路。
    zhwguest
        83
    zhwguest  
       63 天前
    月经贴啊。。。。
    woodfizky
        84
    woodfizky  
       63 天前
    合适就好,当你有选择的自由的时候都好说,反正没必要因为要强行套 restful 给自己上条条框框上枷锁,取其精华去其糟粕。
    ivvei
        85
    ivvei  
       63 天前
    RESTful 就是 SB 玩意。
    nekoneko
        86
    nekoneko  
       63 天前
    @proxychains #38
    PUT 全覆盖修改
    PATCH 部分修改
    morenacl
        87
    morenacl  
       63 天前
    擦,那些所谓的等保+安全公司基本快把 GET 都禁掉啦,已经堕落到全 POST
    ivvei
        88
    ivvei  
       63 天前
    @hxysnail

    五花八门:
    POST /Datas # 新增
    POST /some/resource/path/_action
    PUT /Datas/{id} # 修改(整体替换)
    PUT /Datas/{id} # 修改(部分更新)


    不要说别人就五花八门,说自己就是合理约定。
    jiayouzl
        89
    jiayouzl  
       63 天前
    按照规范肯定是 PUT 、PATCH 、DELETE.当然 get,POST 也可以,一切看自己需求.
    romisanic
        90
    romisanic  
       63 天前
    选择用不用一套规风格也能用出优越感来,神奇
    更用此来评定与自己不同的别人是 SB/垃圾,这才是真正的 SB&垃圾啊
    ming7435
        91
    ming7435  
       63 天前
    X 银行安全团队只接受 GET / POST, 其他一律视为漏洞
    cxxnullptr
        92
    cxxnullptr  
       63 天前
    建议学习一下 restful ,用起来比纯 POST 爽多了
    momo24672
        93
    momo24672  
       63 天前
    @lesismal 可以选择不使用 Restful ,RPC 或者 GraphQL 都可以。
    但是 POST 一把梭的肯定是 SB
    momo24672
        94
    momo24672  
       63 天前
    @flyqie 所以世界是草台班子
    momo24672
        95
    momo24672  
       63 天前
    用了 K8S 之后,其实更推崇谷歌这一套设计 https://cloud.google.com/apis/design/resources
    zhao8681286
        96
    zhao8681286  
       63 天前
    你们推荐 RESTful 有考虑过测试同学的感受模 默认 F12 fetch 一堆 Name 为 1 1 1 1 1 1 1 1 的请求。
    jackerbauer
        97
    jackerbauer  
       63 天前
    post 吧,没那么多事,我们的为了实现业务的
    icy37785
        98
    icy37785  
       63 天前 via iPhone
    @momo24672 #9 你一边说可以选择 RPC 或者 GraphQL 了一边又说 POST 一把梭的肯定是 SB 。
    那你打算怎么用 GraphQL 。
    hxysnail
        99
    hxysnail  
       63 天前   ❤️ 2
    @ivvei #88 咱不杆哈

    ①部分修改那里,我把 Method 打错了,应该是 PATCH
    ②我不知道前面那里那个地方五花八门了。拿我们自定义的 action 部分来说,我们至少保障 action 是一致的,想搜索数据就调_search 接口,比如:

    - POST /Datas/_search
    - POST /Hosts/_search
    - POST /BusinessSystems/_search

    再比如,我们所有软删除数据接口,action 都是_markDeleted ,不会 A 叫 softDelete ,B 叫 softRemove

    - POST /Datas/{id}/_markDeleted
    - POST /Hosts/{id}/_markDeleted
    - POST /BusinessSystems/{id}/_markDeleted

    /some/resource/path 只是想表达有些 action 是在数据集上,比如/Datas ;有些 action 是在单个数据记录上,比如/Datas/{id};甚至有些 action 是在子数据上,比如/Datas/{id}/SubDatas/{subid}。

    哪里五花八门了?

    你不会看到/some/resource/path 跟/Datas 不一样就觉得五花八门吧……

    我通篇都在强调统一一致的范式,而不是在强调就应该采用跟我一样的思路。我不在乎范式是什么,我反对前后不一致,没有任何规则的 POST 而已。

    “不要说别人就五花八门,说自己就是合理约定。”你这么说不就想说别人双标嘛……还真不是……

    今天想起要回这个贴,是因为上周我手下的人刚别其他项目的接口坑了一下。他们告诉我的人,要换个接口,返回的数据字段没变。我的人就去换了,因为对方说接口一样,数据字段没变,他们就偷懒没验证。结果上生产就出了个小问题,因为数据有个字段结构不太一样……

    同一个字段,有一个接口是返回逗号分隔的字符串,另一个返回一个字符数组……理论上,同一种数据,不同的查询场景,返回的数据字段结构没必要不一样吧?这才是我强调的五花八门。

    然后,我在自己项目的开发群里强调了范式规范,不知怎么发图片,直接贴我说的文字:

    理论上,接口再垃圾,只要我们验证充分,问题肯定不会到生产上。
    就算接口不好,最多也只是在开发阶段被坑,影响你的研发效率而已。
    冤有头,债有主,谁坑你就去怼谁。
    我以前经常跟你们强调,字段命名要前后一致,严禁五花八门,最近几次缺陷就是典型的案例。质疑别人前,我们自己要先做到这一点。

    注意看, [质疑别人前,我们自己要先做到这一点。] 我们对自己的水平心里有数。
    lesismal
        100
    lesismal  
       63 天前
    @momo24672 我就很喜欢 post 一把梭.
    聊点具体的, 你没有限定范围, 就以 api 为例, 请问 post 一把梭哪里 sb 了?
    1  2  
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2902 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 32ms · UTC 13:23 · PVG 21:23 · LAX 06:23 · JFK 09:23
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.