PTT職涯區 / Soft_Job (軟體人)

[請益] 怎麼處理API版本不同的問題?

看板Soft_Job (軟體人)作者 (再回頭已是百殘身)時間4年前 (2021/06/28 18:28), 4年前編輯推噓13(13推 0噓 28→)
留言41則, 21人參與, 4年前最新討論串1/1
我是後端工程師 要寫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都是只加不刪嗎 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 61.220.158.181 (臺灣) ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1624876117.A.086.html
→
06/28 18:36, 4年前 , 1F
看樣子應該沒有做版號?
06/28 18:36, 1F
推
06/28 18:40, 4年前 , 2F
API endpoint 可以加版號上去啊 例如： /api/v1/xxx
06/28 18:40, 2F
推
06/28 18:56, 4年前 , 3F
app做強制更版機制，這樣就不用永遠向下相容
06/28 18:56, 3F
呃.. 但我們同一套程式新舊兩個app是分開的 因為改動非常大，所以pm說就是用一個新的殼去包，但考量到有些用戶沒有裝我們新的 app,所以就變成後端API要讓前端新舊版本都能用 ※ 編輯: a88241050 (123.192.130.8 臺灣), 06/28/2021 19:03:52
→
06/28 19:02, 4年前 , 4F
這app若不是很重要 用戶看到強更直接刪除
06/28 19:02, 4F
→
06/28 19:29, 4年前 , 5F
1. API 分版號 2. 給 Web 跟給 App 的API 拆成兩組
06/28 19:29, 5F
推
06/28 19:39, 4年前 , 6F
不知道你的語言，java的話有幾個API版本方式可以挑著
06/28 19:39, 6F
→
06/28 19:39, 4年前 , 7F
用，URL(上面大大提到的)、param、header、accept he
06/28 19:39, 7F
→
06/28 19:39, 4年前 , 8F
ader(produce)
06/28 19:39, 8F
推
06/28 20:34, 4年前 , 9F
靠傳參數處理，沒傳就走舊的邏輯，參數來源塞哪都行
06/28 20:34, 9F
推
06/28 20:38, 4年前 , 10F
最好還是把APP獨立用的接口分出來放，或加版號
06/28 20:38, 10F
→
06/28 21:07, 4年前 , 11F
重點是不是先交代一下這麼多舊版本必要存在的原因
06/28 21:07, 11F
→
06/28 21:08, 4年前 , 12F
第一要考驗db migration的功力 接著遲早某些版本要廢棄
06/28 21:08, 12F
推
06/28 21:11, 4年前 , 13F
如果全部都要相容，那為什麼要切版本?
06/28 21:11, 13F
→
06/28 21:18, 4年前 , 14F
你可能沒權力決定 如果是我 這樣混亂與混用太嚴重
06/28 21:18, 14F
→
06/28 21:18, 4年前 , 15F
我會直接管理面結合市場面 切一個大版本 分開出來
06/28 21:18, 15F
→
06/28 21:19, 4年前 , 16F
這需要你向上管理 新版本不向後支援 你也沒聽過edge
06/28 21:19, 16F
→
06/28 21:19, 4年前 , 17F
還要兼容 ie6
06/28 21:19, 17F
推
06/28 21:22, 4年前 , 18F
這也要說一下中國手機超多自建的瀏覽器，爛到流湯
06/28 21:22, 18F
→
06/28 21:22, 4年前 , 19F
可是有人客群在那邊，還是要支援，各種JS神奇錯誤
06/28 21:22, 19F
→
06/28 21:23, 4年前 , 20F
還有CSS問題，都接近無解的
06/28 21:23, 20F
→
06/28 22:27, 4年前 , 21F
API不可能無限向下支援 那只會造成往後的困擾
06/28 22:27, 21F
→
06/28 22:28, 4年前 , 22F
該捨棄的還是要捨棄
06/28 22:28, 22F
→
06/28 22:59, 4年前 , 23F
新舊API要分開阿..
06/28 22:59, 23F
推
06/28 23:27, 4年前 , 24F
這年頭還要讓菜鳥去麻煩這種困擾 我覺得你們公司人的問題
06/28 23:27, 24F
→
06/28 23:27, 4年前 , 25F
比較大
06/28 23:27, 25F
→
06/28 23:29, 4年前 , 26F
上面推文的方法己經普遍使用超過十年 運作起來符合也符合
06/28 23:29, 26F
→
06/28 23:29, 4年前 , 27F
你的需要 但你的前輩一直沒去調應該不是技術面問題
06/28 23:29, 27F
推
06/29 00:15, 4年前 , 28F
分兩組API吧
06/29 00:15, 28F
推
06/29 01:34, 4年前 , 29F
當初沒切清楚 後面沒人想管 今天就爛到流湯 真的覺
06/29 01:34, 29F
→
06/29 01:34, 4年前 , 30F
得很痛苦看你要不要提議翻新，被打槍就讓他去吧
06/29 01:34, 30F
推
06/29 09:16, 4年前 , 31F
切版本啊 看要切在route 還是你要用一個header
06/29 09:16, 31F
推
06/29 12:44, 4年前 , 32F
API一定可以分更細 有新功能就塞進舊的API只代表初始階
06/29 12:44, 32F
→
06/29 12:44, 4年前 , 33F
段就沒規劃好
06/29 12:44, 33F
推
06/29 13:12, 4年前 , 34F
一是api路徑帶版本，二是讀取user-agent判斷client版本
06/29 13:12, 34F
→
06/29 18:59, 4年前 , 35F
看看graphQL
06/29 18:59, 35F
→
06/29 23:20, 4年前 , 36F
適時整理一波就對了 不要到變成屎山
06/29 23:20, 36F
→
06/29 23:24, 4年前 , 37F
工具沒有完美的 很多都有局限性 有些甚至難用
06/29 23:24, 37F
→
06/29 23:24, 4年前 , 38F
弄到很好難道不是整理的人的功勞嗎 XD
06/29 23:24, 38F
→
07/01 20:56, 4年前 , 39F
只能等強制 APP 更版的時候把 API 切開了吧...
07/01 20:56, 39F
→
07/02 13:54, 4年前 , 40F
靠傳參?
07/02 13:54, 40F
→
07/02 13:57, 4年前 , 41F
或者用版本path隔開 舊的做成wrapper包新的api
07/02 13:57, 41F
‣ 更多 a88241050 的文章
文章代碼(AID): #1WsQHL26 (Soft_Job)
Soft_Job 近期熱門文章
更多 近期熱門文章 >>
PTT職涯區 即時熱門文章
更多 即時熱門文章 >>
‣ 更多 a88241050 的文章
文章代碼(AID): #1WsQHL26 (Soft_Job)