楼主:
a88241050 (å†å›žé 已是百殘身)
2021-06-28 18:28:35我是后端工程师
要写API给WEB跟APP前端
WEB跟APP有些API共用有些没有
后端就只有一个STA版本
也就是说一个版本要同时满足APP和WEB的需求
但我们PROD的上线时间又不是统一的
有可能今天APP要上一个新的功能
所以APP和后端都要更版
但因为WEB没有要更新
所以后端API要同时满足前端新旧版本的需求
讲白一点就是"只能加key,不能删key"
久而久之就会看到一只API回了几十个key
但实际上前端很多key都没用到
那只API就会变得很杂
我们现在每个Vo动不动就2,30个key
有时看程式会看得很乱
不知道大家都怎么处理这种问题?
资深前辈是跟我说改API都一定要向前相容
因为你不能保证用户是否用最新版本
所以key都是只加不删吗
作者:
bill0205 (善良的小孩没人爱)
2021-06-28 18:36:00看样子应该没有做版号?
作者:
codepo (codenfu)
2021-06-28 18:40:00API endpoint 可以加版号上去啊 例如： /api/v1/xxx
作者:
abcf (悠哉悠哉的鱼)
2021-06-28 18:56:00app做强制更版机制，这样就不用永远向下相容
作者:
MoonCode (MoonCode)
2021-06-28 19:02:00这app若不是很重要 用户看到强更直接删除
1. API 分版号 2. 给 Web 跟给 App 的API 拆成两组
作者:
BlacksPig (Black Handsome s Pig)
2021-06-28 19:39:00不知道你的语言，java的话有几个API版本方式可以挑着用，URL(上面大大提到的)、param、header、accept header(produce)
作者:
jack0204 (Jarbar王朝)
2021-06-28 20:34:00靠传参数处理，没传就走旧的逻辑，参数来源塞哪都行最好还是把APP独立用的接口分出来放，或加版号
作者:
kvjo (同名专辑)
2021-06-28 21:07:00重点是不是先交代一下这么多旧版本必要存在的原因
第一要考验db migration的功力 接着迟早某些版本要废弃
作者:
kvjo (同名专辑)
2021-06-28 21:18:00你可能没权力决定 如果是我 这样混乱与混用太严重我会直接管理面结合市场面 切一个大版本 分开出来这需要你向上管理 新版本不向后支援 你也没听过edge还要兼容 ie6
作者:
jack0204 (Jarbar王朝)
2021-06-28 21:22:00这也要说一下中国手机超多自建的浏览器，烂到流汤可是有人客群在那边，还是要支援，各种JS神奇错误还有CSS问题，都接近无解的
作者:
bill0205 (善良的小孩没人爱)
2021-06-28 22:27:00API不可能无限向下支援 那只会造成往后的困扰该舍弃的还是要舍弃
作者:
ldkrsi (衰神)
2021-06-28 23:27:00这年头还要让菜鸟去麻烦这种困扰 我觉得你们公司人的问题比较大上面推文的方法己经普遍使用超过十年 运作起来符合也符合你的需要 但你的前辈一直没去调应该不是技术面问题
当初没切清楚 后面没人想管 今天就烂到流汤 真的觉得很痛苦看你要不要提议翻新，被打枪就让他去吧
作者: wxywxywxy 2021-06-29 09:16:00
切版本啊 看要切在route 还是你要用一个header
API一定可以分更细 有新功能就塞进旧的API只代表初始阶段就没规划好
一是api路径带版本，二是读取user-agent判断client版本
作者: hhsu16 (caveman) 2021-06-29 18:59:00
看看graphQL
作者: superpandal 2021-06-29 23:20:00
适时整理一波就对了 不要到变成屎山工具没有完美的 很多都有局限性 有些甚至难用弄到很好难道不是整理的人的功劳吗 XD
作者:
jim7434 (敬)
2021-07-01 20:56:00只能等强制 APP 更版的时候把 API 切开了吧...
靠传参?或者用版本path隔开 旧的做成wrapper包新的api