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

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

  •  
  •   daguaochengtang · 106 天前 · 1717 次点击
    这是一个创建于 106 天前的主题,其中的信息可能已经有所发展或是发生改变。
    是这样,我是前端,但是最近打算学写 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   106 天前
    1.也没说 rest 就不准带参数了啊,不都是 filter 么

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

    req.getAnimals(id)

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

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

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

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

    至于 url_path 和 query_string
    这个比较混乱

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


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

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

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

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

    我对外提供的大部分 api 都是既支持 post 也支持 get,就是因为对接方水平参差不齐,光一个 put 就够就扯半天的。
    关于   ·   帮助文档   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   3889 人在线   最高记录 5497   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 21ms · UTC 08:09 · PVG 16:09 · LAX 01:09 · JFK 04:09
    ♥ Do have faith in what you're doing.