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

后端接口规范问题,只提供一个接口如何?

  •  1
     
  •   lbunderway · 97 天前 · 6524 次点击
    这是一个创建于 97 天前的主题,其中的信息可能已经有所发展或是发生改变。

    一个后端服务只向外提供一个借口,全用 post ,通过定义不同的业务 code 进行处理,我之前有个小系统就这样搞过,并且我还觉得前端反而会不会简单些,只用一个接口,而有的项目用 rest 风格,有的反而有点不伦不类,大佬些觉得如何呢

    79 条回复    2024-01-12 17:55:08 +08:00
    klo424
        1
    klo424  
       97 天前
    没啥大问题,适合接口较少的情况。
    Akitora
        2
    Akitora  
       97 天前 via Android
    POST /grpc/namespace.service
    XCFOX
        3
    XCFOX  
       97 天前   ❤️ 28
    你是否在找 GraphQL ?
    coderxy
        4
    coderxy  
       97 天前
    让客户端跟服务端建立一个 tcp 长连接,所有的请求都走这个连接都没啥问题, 只要能业务跑起来。
    tomatocici2333
        5
    tomatocici2333  
       97 天前
    比较少随便搞
    pengtdyd
        6
    pengtdyd  
       97 天前
    GraphQL + 1
    feitxue
        7
    feitxue  
       97 天前
    之前有家公司接入的三方接口就是这样设计的,所有功能的入口都是一个“/api/course.api.php”,每一个不同功能,get 参数和 requestbody 都不同。
    反正能用就行。不知道他们怎么维护的。
    有兴趣可以围观他们的文档 https://docs.eeo.cn/api/zh-hans/user/registerMultiple.html
    rimutuyuan
        8
    rimutuyuan  
       97 天前   ❤️ 1
    michaelliuyang
        9
    michaelliuyang  
       97 天前
    我们的产品比较大,接口也较多。没有使用 rest 规范(之前是,改过来了)。API 只有 GET 和 POST ,不允许 Path Variable 传参,GET 参数必须是 Params 方式,POST 参数必须是 Body 的 JSON 方式。这样相对比较好维护,在 AOP 切面做事情,标准少,且统一。
    shyangs
        10
    shyangs  
       97 天前
    可以.

    你可以在 PPT 寫這是 JSON-RPC / GraphQL 顯得高大上.
    InDom
        11
    InDom  
       97 天前   ❤️ 8
    没区别,相当于重新实现了某些 path 到 route 的过程而已。
    sss15
        12
    sss15  
       97 天前
    顺丰开放平台的 api 接口就是这种模式,根据业务 code 来判断你请求的什么接口
    djkloop
        13
    djkloop  
       97 天前
    @feitxue 只要我参数够多,就没有完不成的需求
    justfindu
        14
    justfindu  
       97 天前
    有啥区别?
    LuckyHJH
        15
    LuckyHJH  
       97 天前
    开发上没啥问题,但是要排查问题或者统计数据的时候会不会麻烦点。譬如某个业务超时了,如何定位?统计请求量的时候是不是还得自己实现?
    janus77
        16
    janus77  
       97 天前   ❤️ 1
    这样的话后端开发的时候就是几十上百个 if else 写成一坨了。作为后端你能接受就好
    batchfy
        17
    batchfy  
       97 天前
    还有一个就是可读性?仅靠 code 区分功能,没有什么语义,api 多了难以通过 api 判断功能。
    adoal
        18
    adoal  
       97 天前   ❤️ 10
    技术品位和艺术审美一样,是要通过见多识广来提升的。
    fzdwx
        19
    fzdwx  
       97 天前
    有区别吗?
    fancy2020
        20
    fancy2020  
       97 天前
    能用,但不优雅
    lovelylain
        21
    lovelylain  
       97 天前
    看你们基础设施,如果监控、频限等都是接口维度,只用一个接口导致都上报到这个接口的话,建议拆分多个接口,如果本身支持根据 code 处理或者小改就能实现,只用一个接口也没啥问题。
    huihuiHK
        22
    huihuiHK  
       97 天前
    简版 Gateway
    woodfizky
        23
    woodfizky  
       97 天前
    请求 url 一样的坏处:
    排障的时候如果看不到请求内容,无法通过 url 本身判断每个请求在干嘛,因为都是一样的。
    (除非你都是 query_param 或者 path_param 传参,但是这样我觉得太蠢了)

    同理,所有基于 url 去做的东西你们都做不了了,权限控制,访问统计,等等。

    当然如果你的系统不会遇到上面的需求或者问题,那好像没啥毛病。
    nhhjhwiner
        24
    nhhjhwiner  
       97 天前
    alipay 的 api 看上去就是一个接口,通过不同方法名进行路由的
    Blank10030
        25
    Blank10030  
       97 天前
    功能少的话可以,功能多起来后还是按服务拆分接口比较符合大众要求。
    watzds
        26
    watzds  
       97 天前
    @janus77 #16 那肯定要写成按 code 注册到一个 map 里,不同 code 调用不同执行器
    vibbow
        27
    vibbow  
       97 天前
    你是否在找:SOAP
    Vegetable
        28
    Vegetable  
       97 天前   ❤️ 2
    你将基础设施的功能用自己的代码实现了一遍,引入了更多风险,但是好处几乎没有。
    wxq844688550
        29
    wxq844688550  
       97 天前
    go522000
        30
    go522000  
       97 天前
    这样的话,后期要加 API 网关比较麻烦。
    lbunderway
        31
    lbunderway  
    OP
       96 天前
    @batchfy 每个 code 肯定是要些注释的
    lc5900
        32
    lc5900  
       96 天前
    我们有个项目和华子对接就是这样,接口他们定的
    dyllen
        33
    dyllen  
       96 天前
    支付宝的接口不就这样吗?就一个 gateway 的地址,所有接口都是这个地址。
    bsg1992
        34
    bsg1992  
       96 天前
    就是 JSON-RPC 其实倒是也可以,这样做的坏处就是,一些成熟的中间件,没法使用
    siweipancc
        35
    siweipancc  
       96 天前 via iPhone
    spring mvc 实现原理就是这个,只有一个 web filter ,那设计就很简单了,重写 condition 解析策略就行。
    回到题干,假设你不是 java 开发,你确定要这么写代码,库支持改造吗?不是不能用,是维护的问题
    SHF
        36
    SHF  
       96 天前
    这就是 http rpc
    coinbase
        37
    coinbase  
       96 天前
    nginx 不好缓存 post ,android 客户端或者 iOS 客户端也不好自动缓存
    zhao8681286
        38
    zhao8681286  
       96 天前
    上面抽一层做网关,就提供一个接口 对应 code 映射到下面服务的接口。
    Nazz
        39
    Nazz  
       96 天前 via Android
    没毛病,JSON-RPC
    Nazz
        40
    Nazz  
       96 天前 via Android
    我现在做的项目,纯 POST 且不含动态路由
    akira
        41
    akira  
       96 天前
    从代码来看,其实没太大区别
    lasuar
        42
    lasuar  
       96 天前
    楼主看起来 web coding 经验还是足,其实你多加考虑后会发现,这与定义多个接口并没有本质上的区别(多个接口仍然可以统一使用 POST 方式)。

    So ,没有必要引入楼上说的其他技术来增加复杂度。
    lasuar
        43
    lasuar  
       96 天前
    @lasuar #42 足=》不足
    lasuar
        44
    lasuar  
       96 天前
    最终如何选择要根据架构体现出来的复杂度/可读性/业务可维护性等多方面来评价,楼主先自行比较一下再做考虑。
    fkdtz
        45
    fkdtz  
       96 天前
    这不就是网关干的事么,所有请求都进网关,网关根据请求特征再决定分发给谁处理。
    IvanLi127
        46
    IvanLi127  
       96 天前 via Android
    想咋搞都行,只要你把配套的开发工具都搞出来就成....
    小项目可以简单点直接硬上,大项目工具链没搞定的话调试会哭死。没有什么诡异的安全需求,不建议自立门户
    dayeye2006199
        47
    dayeye2006199  
       96 天前 via Android   ❤️ 1
    恭喜你发明了 graphql 我的朋友
    314696645142
        48
    314696645142  
       96 天前
    能跑就行
    lianglianglee
        49
    lianglianglee  
       96 天前
    aliyun 的控制台和 OpenAPI 就是这样,配置化接入。

    我司的 OpenAPI 也是参考这样的风格,提供了日志,告警,授权,接口方只需要关注实现即可
    sayitagain
        50
    sayitagain  
       96 天前
    @feitxue 我也搞过这样的。。。我猜是$$action(),action 参数是具体调用的方法名。。。
    jonsmith
        51
    jonsmith  
       96 天前
    另类的代价是无法跟同行工具兼容,各种轮子自己造。如果不是非要如此,遵守行业规范不是更好吗?
    tairan2006
        52
    tairan2006  
       96 天前
    这么设计只会更复杂,何必呢
    chenzhengjian
        53
    chenzhengjian  
       96 天前
    这不就是网关?
    Torpedo
        54
    Torpedo  
       96 天前
    想到一个好处,浏览器 get 不能发 body 。这本就导致很多中查询接口设计很难用 get 。比较难以 restful
    thetbw
        55
    thetbw  
       96 天前
    支付宝不就是这种,只有一个网关接口,然后根据请求 method 字段,网关分发到具体业务
    zjcoding
        56
    zjcoding  
       96 天前
    去看下 leetcode 的接口,GraphQL
    ZeroDu
        57
    ZeroDu  
       96 天前
    grpc 一步到位
    est
        58
    est  
       96 天前   ❤️ 1
    sql-over-http
    leojia
        59
    leojia  
       96 天前 via Android
    这不就是 graphql
    WashFreshFresh
        60
    WashFreshFresh  
       96 天前
    我司就是这样,只能说爽的地方很爽,痛苦的地方也可很痛苦。一个接口+dubbo+反射,我感觉金融是不是都这样。
    dbit
        61
    dbit  
       96 天前 via Android
    都是同一个路径,f12 抓接口的时候 看谁会恼火
    hxysnail
        62
    hxysnail  
       96 天前
    其实重点不是一个接口还是多个接口的问题,甚至我们可以这么理解: http 协议它就是一个接口!为什么呢?——通过 method 、path 、header 、body 来区分不同的业务功能,跟你通过 body 里面的 code 字段还有其他业务数据一个道理。

    那么,重点是什么呢?重点是设计哲学——对不同业务进行分析,总结共性,做适当抽象,并最终形成一套严谨、一贯的规则(或者说约定)。不管是 rest 风格,还是就根据 code 进行处理,都是一样的。

    但话说回来,rest 确实有它的缺陷,比如用 method 来表达动作,用 statuscode 来表现结果,由于 method 和 statuscode 无法根据业务自由扩展(特别是 method ,你很难新增一种新 method ),在复杂的业务面前,有点束手束脚。其他的倒还好。
    rickiey
        63
    rickiey  
       96 天前
    这就是 JSON-RPC ,以太坊等区块链项目就这么搞的,一个接口,后端用的反射实现的,也非常方便
    zengzizhao
        64
    zengzizhao  
       96 天前
    @watzds #25 是的
    SenLief
        65
    SenLief  
       96 天前
    @feitxue classin 这个奇葩,我之前看还有点奇怪。
    SenLief
        66
    SenLief  
       96 天前
    @janus77 先判断一手 code 呗,就像出错的 error 不也都是用 code 。
    yueye115
        67
    yueye115  
       96 天前
    我感觉 GraphQL 挺好, 但是前端小哥会抱怨他们要做的工作多了
    Hieast
        68
    Hieast  
       96 天前
    只需要遵循 restful 架构,就很容易在网关层面做请求监控、报警、业务分析,否则这些都需要额外的开发量。
    flytsuki
        69
    flytsuki  
       96 天前
    能用但不建议,不跟着标准来以后有其他需求就要自己造轮子
    Aresxue
        70
    Aresxue  
       96 天前
    小应用随便玩,大的这么玩,基于 http 接口的文档生成工具比如 swagger 就废了,你要自己手写接口文档还要维护,静态代码分析系统也没啥用了,一个应用就一个接口要干啥肯定不知道,全链路系统好一点,但也只能用 tid 去查,其它维度的查询都废了,监控告警系统基于接口的统计比如调用量、平均 rt 、95 线、97 线、99 线也都无了,简而言之可观测性被你全废了。
    auh
        71
    auh  
       96 天前
    没毛病,怎么简单怎么来。
    szdubinbin
        72
    szdubinbin  
       96 天前   ❤️ 1
    有一个微小的问题,debug 的时候,从 chrome 控制台看到全是一个 path ,我估计前端找问题急起来得疯 : )。
    james2013
        73
    james2013  
       96 天前
    只用一个接口对前端和后端都很恶心
    前端:使用不同的接口名称,接口文档方便调试和排除问题
    后端:本来接口自然是解耦的,居然要耦合在一起,写一大堆的判断和跳转,出了问题排除会更麻烦
    way2create
        74
    way2create  
       96 天前
    @feitxue 感觉是那种非常老的 php 项目
    way2create
        75
    way2create  
       96 天前
    你要是只用一个接口 代码都写在一起 那多了就不好维护 小的也还行 你要只是路由格式的问题 那你爱怎么用怎么用 遵守自己的规范或者公开的规范也行 说白了不就是解析路由的规则不同了 正常解析分发到不同的地方处理并不会存在楼上说的都是 if else 的情况
    xiaoHuaJia
        76
    xiaoHuaJia  
       96 天前
    前端在头信息写入请求业务 code,然后后端采用策略设计模式分发到不同 server 就行了,小项目无所叼为
    rainABC
        77
    rainABC  
       95 天前
    @feitxue 这种多了去,一个入口,后面加一个 ? method =xxxxxxxxxxx
    clow
        78
    clow  
       95 天前
    GraphQL + 1
    lululau
        79
    lululau  
       95 天前
    这叫一个接口? example.com:443/api1, example.com:443/api2 用的是同一台机器的同一个 TCP 端口,是不是也可以叫一个接口?
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   5063 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 33ms · UTC 09:41 · PVG 17:41 · LAX 02:41 · JFK 05:41
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.