springmvc使用@requestMapping與用參數(shù)指定方法名轉(zhuǎn)發(fā)的優(yōu)缺點(diǎn)？

1.問題：
在對接一些平臺的時候，發(fā)現(xiàn)接口調(diào)用方式不同了，這樣子做是有什么好處么？
舉個例子：
某平臺的v1版本是一個接口一個路徑的方式：(@RequestMapping的形式)

  如：查詢用戶信息接口是這樣的，http://xxxxx.com/v1/getUserInfo
      查詢用戶余額接口是這樣的,http://xxxxx.com/v1/getUserBanlance

v2版本變成傳參code來決定調(diào)用方法:

  如：查詢用戶信息接口是這樣的，http://xxxxx.com/v2/commonRequest?code=getUserInfo
      查詢用戶余額接口是這樣的,http://xxxxx.com/v2/commonRequest?code=getUserBanlance

2.求助
冒昧說下我自己的觀點(diǎn)，v2版本這種方式需要獲取到code參數(shù)，并且使用反射的方式去調(diào)用對應(yīng)方法，效率豈不是更加低一些，這么設(shè)計(jì)的優(yōu)點(diǎn)在哪里呢？希望能得到大家的幫助。

回答

編輯回答

別傷我

api安全設(shè)計(jì)、精簡思想，提高安全性，符合rest api設(shè)計(jì)風(fēng)格，加一個router而已，對效率影響微乎其微?，F(xiàn)在各大公司都紛紛開始使用這種方式了。

想象一下你的app有一萬個業(yè)務(wù)，你需要一萬個接口嗎？維護(hù)成本怎么算，重構(gòu)怎么算，迭代怎么看，code reviewer 怎么說？這些問題都會冒出來的，現(xiàn)在一個統(tǒng)一入口，統(tǒng)一路由，一目了然。
再比如你抓取某app的數(shù)據(jù)，發(fā)現(xiàn)他們的api好多啊，而且請求頭、參數(shù)什么的全部暴露出來了，安全性不高的api基本就是羊毛黨的口頭肉，統(tǒng)一API入口后，會發(fā)現(xiàn)想要拼接模擬api的難度系數(shù)上升了。

2017年9月16日 13:32

編輯回答

荒城

其實(shí)我覺得實(shí)現(xiàn)中是否使用了反射或者任何細(xì)節(jié)技術(shù)不是判定一個API設(shè)計(jì)優(yōu)劣的先決條件，如題主描述的場景，用V1還是V2其實(shí)取決于對兩個業(yè)務(wù)耦合內(nèi)聚的理解。V2對用戶來說，查詢用戶信息和查詢余額就是同一接口，通過傳入不同的參數(shù)來獲得不同的數(shù)據(jù)。
我個人倒覺得V1更符合RestFul API的設(shè)計(jì)理念，也是結(jié)合這兩個接口其實(shí)不太相同，至少返回上一個是用戶信息，一個是余額，語義差別較大。至于實(shí)現(xiàn)上，第一種其實(shí)同樣也可以通過反射實(shí)現(xiàn)。同樣，第二種也可以不通過反射。
總之，API的設(shè)計(jì)不看后端實(shí)現(xiàn)，只看最后出來的URL長什么樣子，綜合來和RestFull是個不錯的規(guī)范，建議參考。
至于實(shí)現(xiàn)上，當(dāng)你發(fā)現(xiàn)有一些無聊代碼時，可能可以使用反射來消除這種無聊代碼，但從我個人來說，不覺得反射用在這個地方用得好，我們其實(shí)更應(yīng)該關(guān)注業(yè)務(wù)代碼中真正需要重構(gòu)的地方。

2017年12月14日 15:11