前言
Spring+SpringMVC+MyBatis+easyUI整合進階篇（一）設計一套好的RESTful API
Spring+SpringMVC+MyBatis+easyUI整合進階篇（二）RESTful API實戰筆記(接口設計及Java后端實現)
Spring+SpringMVC+MyBatis+easyUI整合進階篇（四）RESTful API實戰筆記(前端代碼修改)
前文中提到了RESTful設計，后端實戰及前端代碼的修改，寫完之后本來想寫一下對RESTful的一些看法的，但是寫着寫着跑題了，最終是寫成了不同階段對於RESTful的認識和感受，包括第一次聽到這個概念，第一次使用這個規范.....一幕幕回想起來也是很有意思的經歷。
初識RESTful
第一次知道這個概念應該是在2014年的時候吧，那時候的我入行不久，接觸JavaWeb開發也只是在入門的水平，做過幾個小的官網項目，開發模式也是跟着公司的開發來，用比較傳統的MVC開發模式，技術選型就是Jsp+Servlet，因此對REST這種思想或者說對於異步調用接口的方式可以說是一竅不通。
看着REST風格的接口URL，當時唯一的想法就是，不就是把".do"去掉嗎？有什么難的？等等，如果把".do"去掉還怎么攔截Servlet的請求？
這就是初識RESTful的情形，第一次接觸RESTful的時候，我的關注點在URL和Servlet攔截配置上，以那時的技術水平和開發經驗來說，似乎也只能意識到這么多，對於RESTful的理解也僅僅在URL的格式不同罷了，至於其他的理解和想法？不存在的。
第一次在項目開發中結合REST實踐
漸漸地，隨着項目經驗的增多，以及自學了一些Java中流行的開發框架，慢慢的就不再選擇使用Jsp+Servlet來開發新項目了，在項目積累中也學到了關於異步調用的知識，學會了使用ajax異步調用接口渲染頁面，這個時候還是沒有想過接口的RESTful化。
第一次試着將RESTful運用到項目開發中是在挺久之后了，一位新同事在看了以往的代碼后，提出想要改動代碼，相對來說他更加有開發經驗，因此就跟着他開始做代碼修改的工作，那時候嘴巴里也整體RESTful來，RESTful去的，其實嘛，也不是很懂，這是真心話，只是聽着老師傅說這么做是去優化代碼的，作為菜鳥的我一聽到項目優化，肯定是樂意去做的。
這是當時的指導文檔，只截了一部分：
項目完成后，改動其實挺多的，配置文件，代碼風格...不過這些都是代碼層面的，暴露出的比較明顯的變化就是接口URL的改變，接口中的".do"、".action"沒了，調用時也增加了調用方法，與之前相比，逼格好像提高了一些！這是當時印象最深刻的感覺了。
但是依然有很多比較搞笑的地方，因為是第一次使用，很多概念其實也不是特別了解，http動詞啊，狀態碼啊，包括REST其實是四個單詞首字母的組合我都不知道，反正第一次使用完全就是個愣頭青，依着葫蘆畫瓢，但是也並沒有畫的很像。
存在的問題很多：
- uri不規范，url命名比較隨便
- 不理解http動詞，post和get方法亂用
- 沒有錯誤處理
- 也沒有跨域處理
.....
回憶起這次經歷，總結起來就是畫虎不成，不懂裝懂，完全是圖個新鮮。不過沒有這次啼笑皆非的經歷我也不會去學習這方面的知識，也算是邁出了第一步吧，雖然樣子比較難看。
RESTful+前后端分離是一個良好的開發實踐
真正大規模使用和深入學習是在一次項目的重構工作中，由於當時的開發人員配置還算可以，就計划將項目拆解為前后端分離的模式，對於開發人員的分工和代碼結構都打算做一次大的改變。一開始依然是懵懵懂懂，隨着學習和使用的深入，也不斷的對之加深了解，對其中的一些知識點和規范也有了自己的看法，比如接口命名，http動詞的使用，接口的版本控制，權限驗證....
由於對RESTful的真正了解是在一次項目的前后端分離實踐中，因此對REST的認識都多多少少的帶有一些前后端分離的想法，並不是說REST一定要和前后端分離這個概念產生必然的聯系，REST用在普通MVC項目中可以嗎？是可以的，前后端分離的項目中調用的接口不符合REST規范可以嗎？也是可以的。其實，REST+前后端分離是一個相對來說不錯的一個開發實踐，對前后端的開發人員都比較友好，當然，這都是個人想法，在實際工作中也是受到了較大的影響，后來的大部分項目開發也基本上都是遵循這種方式，除非有特殊情況。
不僅僅只有RESTful
在網站或者應用的開發中，數據傳輸方式不僅僅只有RESTful一種規范，比如傳統的MVC模式的開發模式中，就是將數據放入model中來實現數據的傳輸，當然，這種方式不是基於接口的方式，基於接口的調用還有webservice方式，我沒有接觸過webservice開發就不多講了，至於其他的還有基於RPC框架的調用方式。
在服務化的討論中目前最風光的應該就是SpringCloud和微服務了吧，由於在SpringCloud技術棧中，各個微服務間調用的方式就是http+json方式，可以很簡單的設計為RESTful架構，因此RESTful概念也隨之又變得火熱和流行起來。
說到這里呢，又引出了一個比較，就是在項目服務化過程中，是選擇使用阿里開源的Dubbo還是Netflix開源的SpringCloud技術棧呢？
為什么提出這個問題呢，因為這兩個技術棧恰好是分別使用了基於http+二進制序列化的RESTful規范(SpringCloud)和基於tcp+二進制序列化的RPC調用方式(Dubbo)，Dubbo是國內較為流行的服務化框架，資歷也較老，而SpringCloud則是目前熾手可熱的后起之秀，關於這二者的比較怕是可以寫出不知多少篇文章了，在這里提到二者之間的比較也是想說明技術選型其實不用拘泥於一種。
REST只是眾多方式中的一種罷了，方法和技術選型真的很多，因此不要標榜其中任何一種方式，也不要鼓吹其中任何一種技術，沒必要，選擇適合你的就好，如果實在不知怎么選，干脆都用一下就好了。
結語
首發於我的個人博客，新的項目演示地址：perfect-ssm,登錄賬號：admin,密碼：123456
如果有問題或者有一些好的創意，歡迎給我留言，也感謝向我指出項目中存在問題的朋友，本篇主要講述了個人對於RESTful的理解。
如果你想繼續了解該項目可以查看整個系列文章Spring+SpringMVC+MyBatis+easyUI整合系列文章,也可以到我的GitHub倉庫或者開源中國代碼倉庫中查看源碼及項目文檔。