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

前后端 页面 url 与 api url 如何统一命名风格.

  •  
  •   dnjat · 229 天前 · 1870 次点击
    这是一个创建于 229 天前的主题,其中的信息可能已经有所发展或是发生改变。
    • 打算把页面 url,与 api url 做一个风格统一,查了许多大佬的文章和分析,最后常用的有 rest,rpc 风格,因为才接触这些风格,恐未掌握其精髓,所以下面定义用了似 rest 风格.希望得到大家的建议与使用经验,哪种风格更适合监控,更加适合应付生产线上碰到的一些 url 问题.

    • rest,用 get,post,put,delete 来定义动作,围着一个地址,好处,简洁.但多语义比较乏力.

    • rpc, 完全用 url 定义作用.

    前端页面

    url -
    /content/{id:123} 内容详细页
    /contents?order=create_time,desc 内容列表页
    /contents/query?create_time=2023/09/01,2023/10/01 搜索
    /content/{id:123}/edi 内容编辑页
    /content/create 内空创建
    /content/edit?id=123 创建编辑页为同一个页面

    供前端调用 api - 似 rpc 风格

    method url -
    get /content/get 单条详细,
    get /content/lists?order=file,desc 列表
    get /content/query?type=best 查询
    post /content/create 新建
    post /content/update 更新
    post /content/delete 删除
    post /content/favorite 收藏

    供前端调用 api - 似 rest 风格

    method url -
    get /contents/{id:123} 单条详细
    get /contents?order=file,desc 列表
    get /contents/query?type=best 查询
    post /contents 新建
    put /contents/{id:123} 更新
    delete /contents/{id:123} 删除
    post /contents/{id:123}/favorite 收藏
    24 条回复    2023-10-15 08:35:17 +08:00
    xiang0818
        1
    xiang0818  
       229 天前
    这个其实无所谓。只是要记得在使用幂等 method 的时候,nginx 默认会超时重试。。。
    caisanli
        2
    caisanli  
       229 天前
    可以在 API 前加个前缀,避免在 history 模式下前端路由和 API 地址冲突。
    javaisthebest
        3
    javaisthebest  
       229 天前
    老老实实地用 RPC Style 吧 Rest 可以滚进教科书里面了

    就打个比方

    /account/query?

    你们产品要求新用户自动创建一个账号 并且在用户侧也提供了隐私&法律信息

    你们前端 后端该怎么理解这个 URL ?

    到底是写接口还是查接口?
    justdoit123
        4
    justdoit123  
       229 天前
    @javaisthebest 哈哈~~ 太真实。 让我想起了 DELETE /user/session/123123123 。 说到底,rest 还是不适合复杂情景。
    thinkershare
        5
    thinkershare  
       229 天前
    楼上一群说 RESTful API 缺陷的,你们到底理不理解这个东西究竟是什么,解决的问题是什么。先学会正确使用这个东西才来谈它的缺陷。
    如果你的 API 是面向浏览器而且是自包含的,我仍然建议你上 RESTful API 。如果你们的团队完全不理解基于资源的 URI Schema 设计. 那就选择 RPC 吧,比较这个玩意不需要动脑子。
    zidian
        6
    zidian  
       229 天前
    老老实实 rpc 吧,rest 都最后都是一团糟。
    dddd1919
        7
    dddd1919  
       229 天前
    rest 的前提是先搞懂 rest ,表格里的列表和查询本就是一个接口/content ,如果需要搜索或排序的话直接在接口上加参数就可以了
    rest 的请求方法定义的是动作,url 对应的是资源,组成一个动宾结构的接口形式,当语义复杂的情况只要定义好资源是什么,很方便就能定义出 url 的格式,如果前后端无法达成对 rest 一致的认知,那趁早放飞,免得进退两难
    dnjat
        8
    dnjat  
    OP
       229 天前
    @xiang0818 是的,只是一个路径风格而已,到了服务器都是一样的. 幂等是要注意的,网络是不能相信的😆
    dnjat
        9
    dnjat  
    OP
       229 天前
    @caisanli /content/create 与/api/content/create 的区分 谢谢提醒
    dnjat
        10
    dnjat  
    OP
       229 天前
    @javaisthebest 这个又到了比写代码还花时间的时候了,我应该把他放在哪合适.我应该叫他什么名字.
    dnjat
        11
    dnjat  
    OP
       229 天前
    @thinkershare 看到的许多博文,大部分都是根据 rest 方式做的分析.所以很想知道这种方式的优势. 如果 api 是面向的还有 app,小程序之类的,也适合 RESTful API 风格吗.
    dnjat
        12
    dnjat  
    OP
       229 天前
    @zidian 之前都是用的似 rpc 方式,感觉换成 rest,像改变行为习惯一样. 没弄好,是会弄得一团糟.😂
    dnjat
        13
    dnjat  
    OP
       229 天前
    @dddd1919 谢谢指出,短短几句比看几篇博文用处更大. 刚又重翻了一篇 rest 看了下, 更感觉这个 rest 像分了类的 graphql. 如果是复杂的语义,只要对参数下手就行了
    thinkershare
        14
    thinkershare  
       229 天前
    @dnjat 如果对你来说,HTTP 协议只是一个传输协议,就像 GRPC 使用 HTTP2 一样,那么这种风格对你来说没什么用处。RESTful API 是个很复杂的东西,它涉及到了最初 HTTP 协议的思想和 WWW 最初诞生的一切都是超链接的理想状态。URI 的设计其实是个复杂的话题,远非很多人想的那么简单。RESTful API 是 HTTP 协议最初的设计者希望人们使用 HTTP 的方式。理想很丰满,显示很骨感,大家都抛弃了 HTTP 本身的很多特性,决定 POST 一把梭,甚至没几个完整看过 MDN 的 HTTP 协议的介绍。如果要想要搞清楚这个问题,需要先研究 HTTP 协议( MDN 的内容就已经够了),如果还想深入理解,最好去看 RESTful API 作者的博士论文。
    另外如果你的程序并不是面向资源,而是本质上就是一个 RPC 模式,前端就是一个 Application,目的就是要发送执行命令调用,用谓词结构的确是最节约时间的。
    如果你的 API 有很多消费者,是面向大众的,有很多客户需要消费你的 API, 那无论是否使用 RESTful API ,你都要好好考虑怎么设计一个文档的 API URI.
    impaul
        15
    impaul  
       229 天前
    作为一个前端程序员,我发现我写的后端接口是 RPC 风格的,因为 PHP 有两个很好用的超级变量 $_GET $_POST 而并没有什么 $_PUT 😂
    dnjat
        16
    dnjat  
    OP
       229 天前
    @thinkershare 非常谢谢,我再去深入了解下 rest 起源. 和名字挂边的最麻烦了😄
    dnjat
        17
    dnjat  
    OP
       229 天前
    @impaul put 也是用的 post body 传输方式,delete 用的 url 传值方式.😄 没用过 php,猜想应该也能用$_GET 和$_POST 获取
    YuJianrong
        18
    YuJianrong  
       229 天前
    我的建议是有条件直接上 Graphql 。
    不要理睬那些 Resuful 原教旨主义者。
    dnjat
        19
    dnjat  
    OP
       229 天前
    @YuJianrong 好早啊,莫非在看 ti?😅 一看你就是 graphql 的受益者,当时一看到 graphql 的统一入口就惊呆了,心想这得多麻烦,全放到一个入口路由.不过他的自由查询还是很喜欢的.
    AquanllR
        20
    AquanllR  
       229 天前
    个人主观提倡:RESTful API
    AquanllR
        21
    AquanllR  
       229 天前
    更加优雅
    flyqie
        22
    flyqie  
       228 天前 via Android
    rest 非常适合 s3 这种跟"资源"概念强关联的业务。

    但它不适合很多的其他场景。。
    dnjat
        23
    dnjat  
    OP
       228 天前
    @AquanllR rest 是非常简洁,聚合强
    dnjat
        24
    dnjat  
    OP
       228 天前
    @flyqie 赞同,看场景.
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   5268 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 54ms · UTC 06:40 · PVG 14:40 · LAX 23:40 · JFK 02:40
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.