作者:
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
作者: jason4571 (terry) 2021-06-29 12:44:00
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