寫在前面的話

看了一下部落格目錄，距離上次更新這個系列的博文已經有兩個多月，並不是因為不想繼續寫部落格，由於中間這段時間更新了幾篇其他系列的文章就暫時停止了，如今已經講述的差不多，也就繼續抽時間更新《Spring+SpringMVC+MyBatis+easyUI整合》這個系列了。

也看到github上有人催更教程，這個真的是沒想到，也謝謝你們的肯定和支援了。

由於《整合優化篇》中關於程式碼優化及資料層優化的文章佔了較大的篇幅，導致遺漏了幾篇原計劃要更新在《整合優化篇》中的文章，關於RESTful的改造和快取功能的整合並沒有做，這段時間會補充進來。

理解RESTful

REST（Representational State Transfer）,中文翻譯叫”表述性狀態轉移”,它首次出現在2000年Roy Fielding的博士論文中，Roy Fielding是 HTTP 規範的主要編寫者之一。他在論文中提到:”我這篇文章的寫作目的，就是想在符合架構原理的前提下，理解和評估以網路為基礎的應用軟體的架構設計，得到一個功能強、效能好、適宜通訊的架構。REST指的是一組架構約束條件和原則。”如果一個架構符合REST的約束條件和原則，我們就稱它為RESTful架構，REST其實並沒有創造新的技術、元件或服務，在我的理解中，它更應該是一種理念、一種思想，利用Web的現有特徵和能力，更好地詮釋和體現現有Web標準中的一些準則和約束。

看完這段理論性的介紹可能並不會使你對於RESTful有任何的想法，甚至只是一掃而過，那就通過實際的案例來講解吧。

首先，這兩個URL都不是RESTful API，因為這兩個URL中都有delete的動作指示，RESTful API是面向資源的架構，因此其URL就應該是一個資源，而且不應該包含任何動作，對於資源的具體操作型別應該由HTTP動詞表示，而不應該是動詞存在於URL中，delete是一個動詞，因此不符合該特點，對於文章刪除功能其對應的RESTful API應該是：
[DELETE] http://ssm-demo.hanshuai.xin/articles/12

常見的RESTful誤區

再講一下一開始接觸RESTful時大家都可能存在的誤區：

• HTTP + JSON = RESTful API,HTTP和JSON不等於RESTful，RESTful特性更加豐富，不能將RESTful簡單的等同於HTTP和JSON。

良好RESTful API的設計原則

關於RESTful API設計的具體實現可以到我的GitHub中檢視，以下為整理的一些設計原則：

基本原則一：URI

• 應該將API部署在專用域名之下：ssm-demo.hanshuai.xin;
• 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.hanshuai.xin/articles   // 新增
2. [GET]    http://ssm-demo.hanshuai.xin/articles?page=1&rows=10 // 列表查詢
3. [PUT]    http://ssm-demo.hanshuai.xin/articles/12 // 修改
4. [DELETE] http://ssm-demo.hanshuai.xin/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.hanshuai.xin/v1/articles?page=1&rows=10 
[PUT]    http://ssm-demo.hanshuai.xin/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，增強安全驗證。

總結

以上做了一些簡單的總結，可能並不是十分的準確，如有錯誤，希望能夠指出我會及時修改，謝謝了。

首發於我的個人部落格，新的專案演示地址：perfect-ssm。

如果有問題或者有一些好的創意，歡迎給我留言，也感謝向我指出專案中存在問題的朋友，具體的功能實現及程式碼邏輯將在之後的文章中介紹。