Spring+SpringMVC+MyBatis+easyUI整合進階篇（六）必定要RESTful嗎？

做者：13
GitHub：https://github.com/ZHENFENG13
版權聲明：本文爲原創文章，未經容許不得轉載。

寫在前面的話

這個問題看起來就顯得有些萌，或者說相似的問題都有些不靠譜，世上哪有那麼多必定的事情，作開發都不必定作多久呢，因此說若是你有這個疑問的話是真真有點兒不着調，不過可能也就是隨口一問吧，沒有深究的必要。既然有人問這個，那麼就再用一篇文章談談RESTful吧，既然談，就不能只是談其優勢，也不能一味的吹捧，也講一下本身的一些理解和不足的地方。

規範、易讀、簡潔？

Spring+SpringMVC+MyBatis+easyUI整合進階篇（一）設計一套好的RESTful API
Spring+SpringMVC+MyBatis+easyUI整合進階篇（二）RESTful API實戰筆記(接口設計及Java後端實現)
Spring+SpringMVC+MyBatis+easyUI整合進階篇（三）使用ajax方法實現form表單的提交
Spring+SpringMVC+MyBatis+easyUI整合進階篇（四）RESTful API實戰筆記(前端代碼修改)
前文中已經談了RESTful很多的優勢，也作了代碼更新，首先，REST強調HTTP應當以資源爲中心，而且規範了資源URI的風格；規範了HTTP請求動做（PUT，POST等）的使用，具備對應的語義；遵循REST規範的Web應用將會得到下面好處：URL具備很強可讀性的，具備自描述性；資源描述與視圖的鬆耦合；可提供OpenAPI，便於第三方系統集成，提升互操做性；若是提供無狀態的服務接口，可提升應用的水平擴展性；

總結下來：規範、易讀，可是這兩個優勢也帶來一些不盡如人意的"反效果":

• 由於RESTful規範較爲明確且有必定的"強制性",這種限制反而致使設計uri變得複雜了，尤爲是複雜的關係，操做，資源集合，硬性套用rest原則設計很是困難。
• 對於RESTful的爭論無處不在，都在討論正確性和規範性，即便和同事之間也會有相似的爭執，當咱們在爭論Restful風格到底如何設計纔是正宗時，發現心中的困惑不只沒有下降，反而增長了。
• RESTful思想及其所倡導的規範很正確，可是使用者的行爲太刻意了反而致使這個東西變了味道，爭來爭去就是爲了證實本身的理解和使用最"正宗"。

RESTful中的模棱兩可

前一個段落可能有些過於概念化了，仍是舉一些具體的例子吧。

案例一

其實，RESTful中也存在着許多的模棱兩可，也有不少不是那麼讓開發人員舒服的地方，有人會去糾結查詢、增長、修改、刪除(對應的方法就是get、post、put、delete)，我的認爲這並不徹底正確，由於這個想法把開發工做中的業務場景過於簡單化和模板化了，咱們開發的功能就只實現這四類操做嗎、若是遇到一些不能徹底對應上這四種方式的業務該怎麼辦呢？

• 發短信、支付、用戶登陸認證，該用get、post、put、delete中的哪個HTTP動詞？
• login和logout應該怎麼REST化？
• 驗證碼發送該如何定義uri？

相似的問題還有不少，感受不少朋友會遇到相似的問題，內心面也有一些不肯定該如何去作，其實在理解了REST後，這些並非什麼無解的難題，只是思惟方式要轉換一下： login和logout其實只是對token或者cookie資源的建立和刪除；業務的uri如何選擇HTTP動詞也要靈活變通，規範是死的，人是活的，按照本身的理解去作，若是後期發現錯誤即便糾正就行了。不過，雖然API如何編寫是開發者的自由，但若是一個API在url裏放一堆動詞、資源設計混亂、各類亂用HTTP Method和Status Code，就太不像話了，規範嘛仍是要遵照的，說了這麼多理解上的誤差，其實代碼質量纔是最重要的，有些手段其實只是讓代碼看起來比較優雅的手段而已。

案例二

以上是針對於RESTful理解和設計上的一個例子，具體工做中還有其餘的例子嗎？也是不少的，好比，比較棘手的一個問題:跨域資源共享 CORS。

在實際進行跨域請求時，常常會遇到相似 No 'Access-Control-Allow-Origin' header is present on the requested resource.這樣的報錯:

這個問題並非由於RESTful引發的，也不能經過修改RESTful的規範去解決，舉這個例子的緣由是由於在接口的RESRful化時也遇到過這個問題，解決辦法就不在本文中列舉了，有興趣的朋友能夠看一下跨域資源共享 CORS 詳解這篇文章，之後有時間會把解決方案整理出來的。

一些須要重視的安全性問題

固然，不止是以上的兩個問題，前一個段落主要是講述了一下理解和具體使用上的問題，這一段講一下可能引起的安全性問題。

遺漏了對資源從屬關係的檢查

一個典型的RESTful的URL會用資源名加上資源的id編號來標識其惟一性，就像這樣:/users/{userid}，例如：/users/100

通常而言用戶只能查看本身的用戶信息，而不容許查看其它用戶的信息。在這種狀況下，攻擊者極可能會嘗試把這個URL裏面的USER ID從100修改成其餘數值，以指望應用返回指定用戶的信息。不過因爲這個安全風險太顯而易見，絕大多數應用都會對當前請求者的身份進行校驗，看其是不是編號爲100的用戶，校驗成功才返回URL中指定的用戶信息，不然會拒絕當前請求。

不經意間泄露的業務信息

以查看用戶信息的RESTful URL爲例：/users/100。因爲用戶ID是一個按序遞增的數字，所以攻擊者既能夠經過ID知道目前應用中的用戶規模，也能夠分別在月初和月末的時候註冊一個用戶，並對比兩個用戶的ID便可知道當前這個月有多少新增用戶。同理，若是訂單號也是按序自增的數字，攻擊者能夠了解到必定時間範圍內的訂單量。

這類ID並不會給應用形成任何技術上的威脅，只是經過ID泄露出來的信息對於你的業務而言可能很是敏感。解決辦法是不使用按序遞增的數字做爲ID，而是使用具備隨機性、惟一性、不可預測性的值做爲ID，最多見的作法就是使用UUID。

參考RESTful架構風格下的4大常見安全問題

選擇適合本身的方式

Spring+SpringMVC+MyBatis+easyUI整合進階篇（五）記錄一下從懵懂到理解RESTful的過程
前一篇博客中也提到了不少其餘的方式，好比傳統的MVC開放形式，好比webservice，好比rpc調用，RESTful也只是其中的一種而已，這些選項中並無高下之分，無非是多種約定俗成的標準，傳統MVC開發着舒服就按MVC模式來開發，習慣用RPC就用RPC，能理解和接受REST就用REST。

前幾篇文章中描述了RESTful那麼多的優勢，如今又說大可沒必要使用，前文又提到RESTful是好的設計實踐，如今又是另一種說法，不是自相矛盾嗎？

這是個人文章，我確定要按照個人一些想法寫啊，可能有不對的地方，前文中提到的是好的設計實踐也是個人我的想法和理解，這篇的開頭就說了，不能只談優勢，因此又列舉了一些不足吧，我寫文章不是挑口水，很不必，選擇適合本身的技術和規範就好。

套用網絡上比較流行的一句話：

聽了不少道理卻依然過很差一輩子。

做爲一名開發人員，本身動手去實踐纔是硬道理，別人說什麼都不要全盤接受，你要想一想適不適合你，適不適合你目前作的項目，鞋合不合適只有腳知道，just do it!

結語

網站的持續運行須要各項基礎設施的搭建，而服務期的續費和維護及各類配套服務的購買也須要必定的費用，但願朋友們給予一點支持，謝謝！

支付寶：微信支付：

優勢也好，缺點也罷，雖然看似也總結了很多，但都是我的看法，確定還有一些遺漏的地方沒有講清楚，還請見諒。

回答文章一開始的問題，是否是必定要用呢？是否是必定要遵循其規則呢？若是不能解決你所面對的問題，不能提升和提高代碼質量、提高工做效率，其實大可沒必要如此介懷，不用就是了。

首發於個人我的博客，新的項目演示地址：perfect-ssm,登陸帳號：admin,密碼：123456

若是有問題或者有一些好的創意，歡迎給我留言，也感謝向我指出項目中存在問題的朋友，本篇主要講述了我的對於RESTful的理解。

若是你想繼續瞭解該項目能夠查看整個系列文章Spring+SpringMVC+MyBatis+easyUI整合系列文章,也能夠到個人GitHub倉庫或者開源中國代碼倉庫中查看源碼及項目文檔。