寫在前面的話
看了一下博客目錄，距離上次更新這個系列的博文已經有兩個多月，並不是因為不想繼續寫博客，由於中間這段時間更新了幾篇其他系列的文章就暫時停止了，如今已經講述的差不多，也就繼續抽時間更新《Spring+SpringMVC+MyBatis+easyUI整合》這個系列了。
也看到github上有人催更教程，這個真的是沒想到，也謝謝你們的肯定和支持了。
由於《整合優化篇》中關於代碼優化及數據層優化的文章占了較大的篇幅，導致遺漏了幾篇原計划要更新在《整合優化篇》中的文章，關於RESTful的改造和緩存功能的整合並沒有做，這段時間會補充進來。
理解RESTful
REST（Representational State Transfer）,中文翻譯叫"表述性狀態轉移",它首次出現在2000年Roy Fielding的博士論文中，Roy Fielding是 HTTP 規范的主要編寫者之一。他在論文中提到:"我這篇文章的寫作目的，就是想在符合架構原理的前提下，理解和評估以網絡為基礎的應用軟件的架構設計，得到一個功能強、性能好、適宜通信的架構。REST指的是一組架構約束條件和原則。"如果一個架構符合REST的約束條件和原則，我們就稱它為RESTful架構，REST其實並沒有創造新的技術、組件或服務，在我的理解中，它更應該是一種理念、一種思想，利用Web的現有特征和能力，更好地詮釋和體現現有Web標准中的一些准則和約束。
看完這段理論性的介紹可能並不會使你對於RESTful有任何的想法，甚至只是一掃而過，那就通過實際的案例來講解吧。
ssm項目中有文章管理這個模塊，文章列表頁面刪除文章請求的服務端API地址為：
http://ssm-demo.hanshuai.xin/article/delete.do,
這個URL並不是RESTful風格的API，稍加修改，URL變成：
http://ssm-demo.hanshuai.xin/article/delete/12,
這樣是不是就是RESTful風格了？
首先，這兩個URL都不是RESTful API，因為這兩個URL中都有delete的動作指示，RESTful API是面向資源的架構，因此其URL就應該是一個資源，而且不應該包含任何動作，對於資源的具體操作類型應該由HTTP動詞表示，而不應該是動詞存在於URL中，delete是一個動詞，因此不符合該特點，對於文章刪除功能其對應的RESTful API應該是：
[DELETE] http://ssm-demo.13blog.site/articles/12
常見的RESTful誤區
再講一下一開始接觸RESTful時大家都可能存在的誤區：
- 一些偽靜態的URL，如http://ssm-demo.13blog.site/contents/12,我們可以通過瀏覽器訪問該URL而獲取信息，但是這並不代表着它就是RESTful API。
- URL里含有queryString就不是RESTful Api，如http://ssm-demo.13blog.site/articles/?page=1&rows=10，RESTful API可以包含queryString。
- HTTP + JSON = RESTful API,HTTP和JSON不等於RESTful，RESTful特性更加豐富，不能將RESTful簡單的等同於HTTP和JSON。
良好RESTful API的設計原則
關於RESTful API設計的具體實現可以到我的GitHub中查看，以下為整理的一些設計原則：
基本原則一：URI
- 應該將API部署在專用域名之下：ssm-demo.13blog.site;
- URL中盡量不用大寫;
- URI中不應該出現動詞,動詞應該使用HTTP方法表示但是如果無法表示,也可使用動詞,例如：search沒有對應的HTTP方法,可以在路徑中使用search,更加直觀;
- URI中的名詞表示資源集合，使用復數形式;
- URI可以包含queryString,避免層級過深。
基本原則二：HTTP動詞
對於資源的具體操作類型，由HTTP動詞表示，常用的HTTP動詞有下面五個：
- GET：從服務器取出資源（一項或多項）。
- POST：在服務器新建一個資源。
- PUT：在服務器更新資源（客戶端提供改變后的完整資源）。
- PATCH：在服務器更新資源（客戶端提供改變的屬性）。
- DELETE：從服務器刪除資源。
還有兩個不常用的HTTP動詞：
- HEAD：獲取資源的元數據。
- OPTIONS：獲取信息，關於資源的哪些屬性是客戶端可以改變的。
例子：
文章管理模塊：
1. [POST] http://ssm-demo.13blog.site/articles // 新增
2. [GET] http://ssm-demo.13blog.site/articles?page=1&rows=10 // 列表查詢
3. [PUT] http://ssm-demo.13blog.site/articles/12 // 修改
4. [DELETE] http://ssm-demo.13blog.site/articles/12 // 刪除
基本原則三：狀態碼（Status Codes）
處理請求后，服務端需向客戶端返回的狀態碼和提示信息。
常見狀態碼(狀態碼可自行設計，只需開發者約定好規范即可)：
- 200:SUCCESS,請求成功;
- 401:Unauthorized,無權限;
- 403:Forbidden,禁止訪問;
- 410:Gone,無此資源;
- 500:INTERNAL SERVER ERROR,服務器發生錯誤。
...
基本原則四：錯誤處理
如果服務器發生錯誤或者資源不可達，應該向用戶返回出錯信息。
基本原則五：服務端數據返回
后端的返回結果最好使用JSON格式。
基本原則六：版本控制
- 規范的API應該包含版本信息，在RESTful API中，最簡單的包含版本的方法是將版本信息放到url中，如：
[GET] http://ssm-demo.13blog.site/v1/articles?page=1&rows=10
[PUT] http://ssm-demo.13blog.site/v1/articles/12
- 另一種做法是，使用HTTP header中的accept來傳遞版本信息。
ssm項目較為簡單，因此暫時沒有加入版本信息。
以下為參考內容，借鑒了一位博主關於安全原則的整理：
安全原則一：Authentication和Permission
Authentication指用戶認證，Permission指權限機制，這兩點是使RESTful API強大、靈活和安全的基本保障。
常用的認證機制是Basic Auth和OAuth，RESTful API開發中，除非API非常簡單，且沒有潛在的安全性問題，否則，認證機制是必須實現的，並應用到API中去。Basic Auth非常簡單，很多框架都集成了Basic Auth的實現，自己寫一個也能很快搞定，OAuth目前已經成為企業級服務的標配，其相關的開源實現方案非常豐富（更多）。
安全原則二：CORS
CORS即Cross-origin resource sharing，在RESTful API開發中，主要是為js服務的，解決javascript調用RESTful API時的跨域問題。
由於固有的安全機制，js的跨域請求時是無法被服務器成功響應的。現在前后端分離日益成為web開發主流方式的大趨勢下，后台逐漸趨向指提供API服務，為各客戶端提供數據及相關操作，而網站的開發全部交給前端搞定，網站和API服務很少部署在同一台服務器上並使用相同的端口，js的跨域請求時普遍存在的，開發RESTful API時，通常都要考慮到CORS功能的實現，以便js能正常使用API。
目前各主流web開發語言都有很多優秀的實現CORS的開源庫，我們在開發RESTful API時，要注意CORS功能的實現，直接拿現有的輪子來用即可。
安全原則三：SSL
http改為https，增強安全驗證。
總結
以上做了一些簡單的總結，可能並不是十分的准確，如有錯誤，希望能夠指出我會及時修改，謝謝了。
推薦一下自己的達人課，感興趣的朋友可以看一下：SSM搭建精美實用的管理系統
首發於我的個人博客，新的項目演示地址：perfect-ssm。
如果有問題或者有一些好的創意，歡迎給我留言，也感謝向我指出項目中存在問題的朋友，具體的功能實現及代碼邏輯將在之后的文章中介紹。
如果你想繼續了解該項目可以查看整個系列文章Spring+SpringMVC+MyBatis+easyUI整合系列文章,也可以到我的GitHub倉庫或者開源中國代碼倉庫中查看源碼及項目文檔。