V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX 提问指南
daguaochengtang
V2EX  ›  问与答

你们平时写接口会遵循 RESTful API 吗?

  •  
  •   daguaochengtang · 2021-07-14 09:43:19 +08:00 · 2694 次点击
    这是一个创建于 988 天前的主题,其中的信息可能已经有所发展或是发生改变。
    是这样,我是前端,但是最近打算学写 api,想试试 RESTful API,看了[阮一峰的这篇文章]( http://www.ruanyifeng.com/blog/2014/05/restful_api.html),在开始前我就想到了可能会遇到的一些问题:

    1. GET 方式参数都拼在 url 上,但是有时候一个接口甚至会携带十几个参数,比如我们现在的后台管理的一些列表就是,这个感觉有点丑
    2. `GET /zoos/ID/animals:列出某个指定动物园的所有动物`,这是文中举的一个例子,要查某个表里某个 id 关联的其它表的数据,需要把 id 放在接口地址上,这样感觉很不好看,前端处理起来也很麻烦。

    我们目前后端基本就是只用 GET 和 POST,甚至直接所有 POST 一把梭。

    想知道各位都是怎么写的,是否有实践过 RESTful 的?以及实际效果怎么样?是否有很多槽点?你觉得哪种方式更好?
    14 条回复    2021-07-14 23:50:33 +08:00
    dzdh
        1
    dzdh  
       2021-07-14 09:49:15 +08:00
    1.也没说 rest 就不准带参数了啊,不都是 filter 么

    2.前端不是应该有封装的统一 request 库么, api 里留占位符啊,反而更清晰了吧

    req.getAnimals(id)

    getAnimals (id) { req.get('/zoos/{id}/animals', {id:33}).filter({}).then(...
    tabris17
        2
    tabris17  
       2021-07-14 09:56:50 +08:00
    复杂查询那就 GraphQL 咯
    Rwing
        3
    Rwing  
       2021-07-14 10:06:16 +08:00
    daguaochengtang
        4
    daguaochengtang  
    OP
       2021-07-14 10:11:11 +08:00
    @dzdh
    1. 你说的 filter 就是我说的查询字符串啊,`?name=xxx&limit=10`,遮掩的参数多了,url 会很长
    2. 相比于 rest,一把梭的写法是这样的:getAnimal() {req.get('/getAnimals', {zoosId: 1, animalId: 1})},所有接口的写法都一个样子

    不是在抱怨 rest,上面的两点是这个规范的特点导致的,但看起来也确实是缺点。
    daguaochengtang
        5
    daguaochengtang  
    OP
       2021-07-14 10:14:32 +08:00
    @Rwing 额,好吧。我之前确实没在 v 站看到过类似的贴子
    baiyi
        6
    baiyi  
       2021-07-14 10:20:19 +08:00
    虽然从 HTTP 方法的语义角度来讲,POST 一把梭的设计也没有什么问题,但是我们在设计 HTTP API 的时候,还是要尽量选用合适的 HTTP 方法,这是 RESTful 设计风格带来的好处,一个 HTTP 请求过程中的所有组件都遵循着这些规则。
    比如 GET,为什么都推荐查询要用 GET,除了 GET 本身的语义,也是因为浏览器等组件为 GET 方法提供的一些其他的机制,最典型的例子就是缓存。

    回到问题:1. Get filter 参数过多,解决方案一般有两个:① 精简参数及 Value,比如用缩写代替完整表述,用“,”、":"表示分割等方法。② 创建 filter 资源,然后用 filterID 进行 GET 查询。这其实是一种争议很大的方法,用起来很麻烦,所以很多人不愿意用。
    就我个人而言,我会尽量使用 ①、如果实在无法使用 ①,我可能在适当的场景下会使用 ②

    问题 2:不好看是主观感受,前端处理麻烦是伪命题,如果前端觉得麻烦只是他没这么做过
    murmur
        7
    murmur  
       2021-07-14 10:23:21 +08:00
    不遵循,根据经验我们的接口都不带重名的,如果没有数据限制,我们 get 和 post 都支持
    balabalaguguji
        8
    balabalaguguji  
       2021-07-14 10:28:27 +08:00
    没必要,怎么方便怎么来,就一个接口而已。
    teekgeek
        9
    teekgeek  
       2021-07-14 10:41:38 +08:00
    目前我看到的
    用 RESTful 规范 顶多也就
    数据增删改查对应到四种 HTTP 请求方法

    至于 url_path 和 query_string
    这个比较混乱

    所以每个接口 都会有一个说明文档
    解释 请求的 URL 以及需要传的参数 参数是否必须
    返回值 返回数据样例


    这个接口说明 目前用的最多的是 swagger
    https://petstore.swagger.io/

    所以前后端分离
    后端写接口 前端调用接口
    必要的协商还是要有的,基本上就是每个接口的文档说明
    EPr2hh6LADQWqRVH
        10
    EPr2hh6LADQWqRVH  
       2021-07-14 10:46:32 +08:00
    现在整个行业都在 HTTP 上面纠结,完全没必要,前后端分离之后,自己抽象 RPC 才是最适当的
    kop1989
        11
    kop1989  
       2021-07-14 10:47:09 +08:00
    RESTful 风格在我看来过于理想化了,目前的实际应用中优先级不高。

    1 、RESTful 风格并没有显著降低 api 的沟通信息量。
    2 、会出现特殊情况。(比如长参数的查询)
    3 、比如楼上提及的针对不同请求方法的浏览器优化(比如 GET 请求的缓存机制),在业务上的优势很小,使用不当造成反效果则是灾难性的。
    Jooooooooo
        12
    Jooooooooo  
       2021-07-14 12:49:19 +08:00
    有没有想过你为啥觉得遵守 RESTful 是好的实践?

    是你见过什么实际项目严格遵守了 RESTful 很不错导致你也想试试吗?
    kuangwinnie
        13
    kuangwinnie  
       2021-07-14 13:57:45 +08:00
    当然呀,一个东西越显式越难犯错误。
    ajaxfunction
        14
    ajaxfunction  
       2021-07-14 23:50:33 +08:00
    约束力太强,随着业务的发展,
    总会有不遵循的地方,那就变成了为遵守而遵守了,反而更麻烦,

    我对外提供的大部分 api 都是既支持 post 也支持 get,就是因为对接方水平参差不齐,光一个 put 就够就扯半天的。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   3085 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 25ms · UTC 12:51 · PVG 20:51 · LAX 05:51 · JFK 08:51
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.