寫(xiě)在前面的話
看了一下博客目錄，距離上次更新這個(gè)系列的博文已經(jīng)有兩個(gè)多月，并不是因?yàn)椴幌肜^續(xù)寫(xiě)博客龟虎，由于中間這段時(shí)間更新了幾篇其他系列的文章就暫時(shí)停止了，如今已經(jīng)講述的差不多沙庐，也就繼續(xù)抽時(shí)間更新《Spring+SpringMVC+MyBatis+easyUI整合》這個(gè)系列了鲤妥。
也看到github上有人催更教程，這個(gè)真的是沒(méi)想到轨功，也謝謝你們的肯定和支持了。
由于《整合優(yōu)化篇》中關(guān)于代碼優(yōu)化及數(shù)據(jù)層優(yōu)化的文章占了較大的篇幅容达，導(dǎo)致遺漏了幾篇原計(jì)劃要更新在《整合優(yōu)化篇》中的文章古涧，關(guān)于RESTful的改造和緩存功能的整合并沒(méi)有做，這段時(shí)間會(huì)補(bǔ)充進(jìn)來(lái)花盐。
理解RESTful
REST（Representational State Transfer）,中文翻譯叫"表述性狀態(tài)轉(zhuǎn)移",它首次出現(xiàn)在2000年Roy Fielding的博士論文中羡滑，Roy Fielding是 HTTP 規(guī)范的主要編寫(xiě)者之一菇爪。他在論文中提到:"我這篇文章的寫(xiě)作目的，就是想在符合架構(gòu)原理的前提下柒昏，理解和評(píng)估以網(wǎng)絡(luò)為基礎(chǔ)的應(yīng)用軟件的架構(gòu)設(shè)計(jì)凳宙，得到一個(gè)功能強(qiáng)、性能好职祷、適宜通信的架構(gòu)氏涩。REST指的是一組架構(gòu)約束條件和原則。"如果一個(gè)架構(gòu)符合REST的約束條件和原則有梆，我們就稱它為RESTful架構(gòu)是尖，REST其實(shí)并沒(méi)有創(chuàng)造新的技術(shù)、組件或服務(wù)泥耀，在我的理解中饺汹，它更應(yīng)該是一種理念、一種思想痰催，利用Web的現(xiàn)有特征和能力兜辞，更好地詮釋和體現(xiàn)現(xiàn)有Web標(biāo)準(zhǔn)中的一些準(zhǔn)則和約束。
看完這段理論性的介紹可能并不會(huì)使你對(duì)于RESTful有任何的想法夸溶，甚至只是一掃而過(guò)逸吵，那就通過(guò)實(shí)際的案例來(lái)講解吧。
ssm項(xiàng)目中有文章管理這個(gè)模塊蜘醋，文章列表頁(yè)面刪除文章請(qǐng)求的服務(wù)端API地址為：
http://ssm-demo.hanshuai.xin/article/delete.do,
這個(gè)URL并不是RESTful風(fēng)格的API胁塞，稍加修改，URL變成：
http://ssm-demo.hanshuai.xin/article/delete/12,
這樣是不是就是RESTful風(fēng)格了压语？
首先啸罢，這兩個(gè)URL都不是RESTful API，因?yàn)檫@兩個(gè)URL中都有delete的動(dòng)作指示胎食，RESTful API是面向資源的架構(gòu)扰才，因此其URL就應(yīng)該是一個(gè)資源，而且不應(yīng)該包含任何動(dòng)作厕怜，對(duì)于資源的具體操作類型應(yīng)該由HTTP動(dòng)詞表示衩匣，而不應(yīng)該是動(dòng)詞存在于URL中，delete是一個(gè)動(dòng)詞粥航，因此不符合該特點(diǎn)琅捏，對(duì)于文章刪除功能其對(duì)應(yīng)的RESTful API應(yīng)該是：
[DELETE] http://ssm-demo.hanshuai.xin/articles/12
常見(jiàn)的RESTful誤區(qū)
再講一下一開(kāi)始接觸RESTful時(shí)大家都可能存在的誤區(qū)：
- 一些偽靜態(tài)的URL，如http://ssm-demo.hanshuai.xin/contents/12,我們可以通過(guò)瀏覽器訪問(wèn)該URL而獲取信息递雀，但是這并不代表著它就是RESTful API柄延。
- URL里含有queryString就不是RESTful Api，如http://ssm-demo.hanshuai.xin/articles/?page=1&rows=10缀程，RESTful API可以包含queryString搜吧。
- HTTP + JSON = RESTful API,HTTP和JSON不等于RESTful市俊，RESTful特性更加豐富，不能將RESTful簡(jiǎn)單的等同于HTTP和JSON滤奈。
<h1>良好RESTful API的設(shè)計(jì)原則</h1>
關(guān)于RESTful API設(shè)計(jì)的具體實(shí)現(xiàn)可以到我的GitHub中查看摆昧，以下為整理的一些設(shè)計(jì)原則：
基本原則一：URI
- 應(yīng)該將API部署在專用域名之下：ssm-demo.hanshuai.xin;
- URL中盡量不用大寫(xiě);
- URI中不應(yīng)該出現(xiàn)動(dòng)詞,動(dòng)詞應(yīng)該使用HTTP方法表示但是如果無(wú)法表示,也可使用動(dòng)詞,例如：search沒(méi)有對(duì)應(yīng)的HTTP方法,可以在路徑中使用search,更加直觀;
- URI中的名詞表示資源集合，使用復(fù)數(shù)形式;
- URI可以包含queryString,避免層級(jí)過(guò)深蜒程。
基本原則二：HTTP動(dòng)詞
對(duì)于資源的具體操作類型绅你，由HTTP動(dòng)詞表示，常用的HTTP動(dòng)詞有下面五個(gè)：
- GET：從服務(wù)器取出資源（一項(xiàng)或多項(xiàng)）搞糕。
- POST：在服務(wù)器新建一個(gè)資源勇吊。
- PUT：在服務(wù)器更新資源（客戶端提供改變后的完整資源）。
- PATCH：在服務(wù)器更新資源（客戶端提供改變的屬性）窍仰。
- DELETE：從服務(wù)器刪除資源汉规。
還有兩個(gè)不常用的HTTP動(dòng)詞：
- HEAD：獲取資源的元數(shù)據(jù)。
- OPTIONS：獲取信息驹吮，關(guān)于資源的哪些屬性是客戶端可以改變的针史。
例子：
文章管理模塊：
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 // 刪除
基本原則三：狀態(tài)碼（Status Codes）
處理請(qǐng)求后，服務(wù)端需向客戶端返回的狀態(tài)碼和提示信息碟狞。
常見(jiàn)狀態(tài)碼(狀態(tài)碼可自行設(shè)計(jì)啄枕，只需開(kāi)發(fā)者約定好規(guī)范即可)：
- 200:SUCCESS,請(qǐng)求成功;
- 401:Unauthorized,無(wú)權(quán)限;
- 403:Forbidden,禁止訪問(wèn);
- 410:Gone,無(wú)此資源;
- 500:INTERNAL SERVER ERROR,服務(wù)器發(fā)生錯(cuò)誤。
...
基本原則四：錯(cuò)誤處理
如果服務(wù)器發(fā)生錯(cuò)誤或者資源不可達(dá)族沃，應(yīng)該向用戶返回出錯(cuò)信息频祝。
基本原則五：服務(wù)端數(shù)據(jù)返回
后端的返回結(jié)果最好使用JSON格式。
基本原則六：版本控制
- 規(guī)范的API應(yīng)該包含版本信息脆淹，在RESTful API中常空，最簡(jiǎn)單的包含版本的方法是將版本信息放到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來(lái)傳遞版本信息漓糙。
ssm項(xiàng)目較為簡(jiǎn)單，因此暫時(shí)沒(méi)有加入版本信息烘嘱。
以下為參考內(nèi)容昆禽，借鑒了一位博主關(guān)于安全原則的整理：
安全原則一：Authentication和Permission
Authentication指用戶認(rèn)證，Permission指權(quán)限機(jī)制蝇庭，這兩點(diǎn)是使RESTful API強(qiáng)大醉鳖、靈活和安全的基本保障。
常用的認(rèn)證機(jī)制是Basic Auth和OAuth哮内，RESTful API開(kāi)發(fā)中盗棵，除非API非常簡(jiǎn)單，且沒(méi)有潛在的安全性問(wèn)題，否則漾根，認(rèn)證機(jī)制是必須實(shí)現(xiàn)的，并應(yīng)用到API中去鲫竞。Basic Auth非常簡(jiǎn)單辐怕，很多框架都集成了Basic Auth的實(shí)現(xiàn)，自己寫(xiě)一個(gè)也能很快搞定从绘，OAuth目前已經(jīng)成為企業(yè)級(jí)服務(wù)的標(biāo)配寄疏，其相關(guān)的開(kāi)源實(shí)現(xiàn)方案非常豐富（更多）。
安全原則二：CORS
CORS即Cross-origin resource sharing僵井，在RESTful API開(kāi)發(fā)中陕截，主要是為js服務(wù)的，解決javascript調(diào)用RESTful API時(shí)的跨域問(wèn)題批什。
由于固有的安全機(jī)制农曲，js的跨域請(qǐng)求時(shí)是無(wú)法被服務(wù)器成功響應(yīng)的。現(xiàn)在前后端分離日益成為web開(kāi)發(fā)主流方式的大趨勢(shì)下驻债，后臺(tái)逐漸趨向指提供API服務(wù)乳规，為各客戶端提供數(shù)據(jù)及相關(guān)操作，而網(wǎng)站的開(kāi)發(fā)全部交給前端搞定合呐，網(wǎng)站和API服務(wù)很少部署在同一臺(tái)服務(wù)器上并使用相同的端口暮的，js的跨域請(qǐng)求時(shí)普遍存在的，開(kāi)發(fā)RESTful API時(shí)淌实，通常都要考慮到CORS功能的實(shí)現(xiàn)冻辩，以便js能正常使用API。
目前各主流web開(kāi)發(fā)語(yǔ)言都有很多優(yōu)秀的實(shí)現(xiàn)CORS的開(kāi)源庫(kù)拆祈，我們?cè)陂_(kāi)發(fā)RESTful API時(shí)恨闪，要注意CORS功能的實(shí)現(xiàn)，直接拿現(xiàn)有的輪子來(lái)用即可缘屹。
安全原則三：SSL
http改為https凛剥，增強(qiáng)安全驗(yàn)證。
總結(jié)
以上做了一些簡(jiǎn)單的總結(jié)轻姿，可能并不是十分的準(zhǔn)確犁珠，如有錯(cuò)誤，希望能夠指出我會(huì)及時(shí)修改互亮，謝謝了犁享。
首發(fā)于我的個(gè)人博客，新的項(xiàng)目演示地址：perfect-ssm豹休。
如果有問(wèn)題或者有一些好的創(chuàng)意炊昆，歡迎給我留言，也感謝向我指出項(xiàng)目中存在問(wèn)題的朋友，具體的功能實(shí)現(xiàn)及代碼邏輯將在之后的文章中介紹凤巨。
如果你想繼續(xù)了解該項(xiàng)目可以查看整個(gè)系列文章Spring+SpringMVC+MyBatis+easyUI整合系列文章,也可以到我的GitHub倉(cāng)庫(kù)或者開(kāi)源中國(guó)代碼倉(cāng)庫(kù)中查看源碼及項(xiàng)目文檔视乐。
