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

关于接口返回值设计问题:服务之间内部调用接口的返回值类型需不需要跟客户端接口保持一致?

  •  
  •   polyang · 2021-06-13 00:07:29 +08:00 · 1888 次点击
    这是一个创建于 1261 天前的主题,其中的信息可能已经有所发展或是发生改变。
    现在盛行微服务,有些接口是仅供服务之间内部调用的,有些接口是提供给客户端的,那么问题来了,这两种类型的接口返回值类型需要保持一致吗?你们是怎么设计的?


    我为什么会有这么疑问呢,因为我在实际开发中发现,如果返回值类型保持一致的话会有一些不方便的地方,比如,客户端接口的返回值一般会有 code,它的值可能会是 200,404,400,500 等等,但服务之间内部调用接口根本不关注这个,只需返回对象里有个布尔类型的变量告诉我调用其他服务到底成功与否就行了,鉴于此,是否可以设计出两种返回值类型?
    9 条回复    2021-06-13 13:13:25 +08:00
    xiangyuecn
        1
    xiangyuecn  
       2021-06-13 00:12:46 +08:00
    “但服务之间内部调用接口根本不关注这个” 不管你是不是内部服务还是客户端,只要你调了接口,你就是客户端。 你在纯粹的增加复杂性和心智负担。
    dayeye2006199
        2
    dayeye2006199  
       2021-06-13 02:51:56 +08:00
    应该保持一致性,像上面说的,内部客户也是客户。
    你这个 code 检查一下是否在某一段范围内,判断调用是否成功不行吗?
    polyang
        3
    polyang  
    OP
       2021-06-13 08:34:26 +08:00
    @xiangyuecn
    @dayeye2006199 你们说的确实有道理。
    xuanbg
        4
    xuanbg  
       2021-06-13 08:47:19 +08:00
    就不能加个布尔类型的 successful ?
    xuanbg
        5
    xuanbg  
       2021-06-13 08:48:57 +08:00
    客户端一般都不关心 code 是啥,只要不成功,抛出 error message 就完事。
    IvanLi127
        6
    IvanLi127  
       2021-06-13 09:40:03 +08:00 via Android
    你觉得客户端会在意这种 code 嘛?可能人家压根也没怎么用过呢 所以你也可以不用呐
    chenshun00
        7
    chenshun00  
       2021-06-13 10:31:25 +08:00
    参考下阿里云的设计应该内外都是保持的一致的,直接暴露的 API,然后不论是内部还是外部都是调用的 API 。
    newtype0092
        8
    newtype0092  
       2021-06-13 12:03:43 +08:00
    如果你说的客户端是一个具体的 toC 的 App,那只应该调用专门给这个 App 提供服务的后端,如果需要其他通用服务,也应该通过 App 后端代理。

    如果客户端是指通用服务的请求方,那么不应该区分内部外部。
    xiaofan2
        9
    xiaofan2  
       2021-06-13 13:13:25 +08:00
    其实一般对外是 API 接口 对内的话都是 rpc 吧 我理解是不是就没有你的这种困扰了?
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   4066 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 31ms · UTC 01:04 · PVG 09:04 · LAX 17:04 · JFK 20:04
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.