疑問？同樣的api商務邏輯，用戶端和WEB需要維護兩套api代碼嗎？

前提：業務內部已經拆成多個微服務

疑問？用戶端和WEB需要維護兩套api代碼嗎？如果只維護一套api,採用跨域或服務內部轉寄合理嗎？

回複內容：

前提：業務內部已經拆成多個微服務

疑問？用戶端和WEB需要維護兩套api代碼嗎？如果只維護一套api,採用跨域或服務內部轉寄合理嗎？

我是以討論的方式回答此問題的

我們目前APP和WEB(PC和移動網頁)盡量都用同一套API，我們現階段也也沒有封裝那麼多的微服務，所以應用程式層和服務層沒有明確的隔離都統一叫做資料API！也是和你一樣考慮到維護成本問題，所以即使APP首頁和網頁首頁 UI一樣的情況下，為了提高APP資料載入速度可能把需要N個請求在API層封裝成了一個獨立的API再調用一次公用API一次性返回所有首頁需要的JSON資料，除了某些下拉才載入的資料!

另外你說的跨域我感覺，你是想用AJAX去直接請求你們的服務API，這個我感覺不合理，必須在項目中用後端語言再調用一次資料API，這樣就不存在跨域問題了也更安全，相當於你的用戶端項目就是你的應用程式層了!

我們最近也碰到了一個糾結的問題，IOS在審核期間的時候，新的API必鬚髮布，但是我們就算從業務角度決定不相容老版本，在審核期間IOS老版本還是會請求出錯，所以我們想了兩個都不算特別好的方案，一個是程式角度做邏輯相容，對於新人來講絕對是一個災難，另外一個是永遠讓APP的版本對應一套API版本，這樣物理上代碼就會多出一份，源碼很臃腫比較頭大，所以藉此貼歡迎一起討論API多版本維護問題！

一般來說，現在採用restful Api設計模式， 只需要維護一套api, 用戶端通過跨域請求來訪問api。

不需要，只要維持相同的api認證方式即可，比如提供者需要帶上access_token

不管你用跨域還是內部轉寄都是湊合方案，既然你的系統已經拆成了兩塊，那介面自然也是兩個獨立的介面，而用戶端也應該獨立的去調用不同的介面。不管你現在直接做還是先用湊合方案解決，終究還是要獨立出來的，不然兩套系統如何解耦？那不和不拆一樣了嗎？

