Restful風格到底是什麼？怎麼應用到我們的專案中？
rest越來越流行，感覺挺高大尚的。網上看了很多網友的說法，各有各的看法，我覺得很多說得很有道理。
說法一
restful風格，就是一種面向資源服務的API設計方式，它不是規範，不是標準，它一種設計模式。以前流行的web service服務都是面向過程，基於RPC協議的SOAP協議，對於現在或者未來，更多的人瞭解並且深受SOA思想影響，以面向服務為目標，而現在的SOAP雖然支援SOA，但存在很很大的差別，所以，慢慢就流行基於restful風格的web service。說簡單一點，就是它純粹面向資源，面向服務的思想，目前J2EE6的JAX-RS就是這種restful風格實現的新技術。
說法二
作者：張立理
連結：http://www.zhihu.com/question/33959971/answer/57593571
來源：知乎
著作權歸作者所有。商業轉載請聯絡作者獲得授權，非商業轉載請註明出處。
阮一峰的那篇文章我認為沒有講到實質，他能讓人大概知道Restful是啥，但無法令人信服地知道REST是一種和以往不同的、在一定場景下有一定優勢的架構方式
REST的全稱在文章裡已經有了，其中的核心是第一個字母R，即資源（Resource）
REST的核心在於，當你設計一個系統的時候，資源是第一位的考慮，你首先從資源的角度進行系統的拆分、設計，而不是像以往一樣以操作為角度來進行設計
我們平時搞系統是這樣的：
1.有新建使用者功能
2.新建使用者需要一個URL
3.往這個URL傳送的資料要定義好
4.開始寫後端和前端
這是以操作為第一位的設計方法，首先我們確認了一個操作，然後圍繞這個操作把周邊需要的東西建設好，這種方式當然可以架構出一個系統，甚至是一個好系統，但是偶爾會有些問題：
1.操作之間是會有關聯，你的設計容易變成“第2個操作要求第1個操作進行過”，這種關係多起來你的系統就亂了
2.你的URL設計會缺乏一致性
3.操作通常被認為是有副作用（Side Effect）的，所以很少有人基於操作去設計快取之類的東西
基於這些問題，我們的另一種方法是基於資源的角度來搞，但這個太難了我至今其實沒想明白到底是怎麼搞的，但基於資源會有一些好處：
1.各個資源雖然可能有關聯，但依舊是能夠簡單地切掉這些關聯導致相互獨立的，所以不會有非常亂的耦合性
2.對資源的操作就這麼幾種，所以很容易設計一致的URL
3.我們明白對資源的讀操作是無副作用的，所以能玩快取
但其實現在99%說自己是REST的情況，就是改了個URL風格，用了用PUT和POST，根本沒有明白REST是一個什麼，也沒有按REST的思想來指導設計，在我看來純粹就是在作秀
要說自己會REST，我覺得至少回答2個問題：
1.對於使用者登入和使用者退出這兩個業務需求，REST指導下的架構和設計如何滿足
2.批量的刪除、修改、新增如何滿足
應題主要求，簡要回答它的優勢或優點。
首先，REST規範：
1.強調HTTP應當以資源為中心，並且規範了資源URI的風格；
2.規範了HTTP請求動作（PUT，POST等）的使用，具有對應的語義；
遵循REST規範的Web應用將會獲得下面好處：
1.URL具有很強可讀性的，具有自描述性；
2.資源描述與檢視的鬆耦合；
3.可提供OpenAPI，便於第三方系統整合，提高互操作性；
4.如果提供無狀態的服務介面，可提高應用的水平擴充套件性；
下面再詳細說明一下REST。瞭解事物，分三步走：
【基本概念】
REST是一種軟體架構模式。核心概念包括：
資源（Resource）：在REST中，資源可以簡單的理解為URI，表示一個網路實體。比如，/users/1/name，對應id=1的使用者的屬性name。
既然資源是URI，就會具有以下特徵：名詞，代表一個資源；它對應唯一的一個資源，是資源的地址。
表現（Representation）：是資源呈現出來的形式，比如上述URI返回的HTML或JSON，包括HTTP Header等；
【實踐】
怎麼用呢？不同的Server端框架提供了各種解決方案。比如JavaEE中的開箱即用的Spring-MVC。
但實踐過程中，你自然會碰到一些需要思考的問題：
1）如何定義資源：一般對應資料庫實體（在傳統的關係型資料庫中）。
2）需要對HTTP協議更多的理解
URL格式：協議://域名/路徑?查詢#HASH，實際的一個HTTP請求，還會包括Header（含Cookie、Method等）
資源的URI格式：協議://域名/路徑，它只是URL的子集，表徵一個資源實體。比如，http://a.com/users/1。
恰當地理解和返回Http Status（狀態碼）。200=成功，404=資源不存在，500=伺服器端錯誤等等。
3）REST操作
一般資源操作只有新增、刪除、查詢、更新，對應HTTP協議中四類請求：POST、DELETE、GET、PUT。其中，後三個操作是冪等的。（什麼是冪等？）
查詢資源時，更多的引數，比如分頁、排序、過濾條件，一般都會放在URL的查詢部分（Query String）。
新增、更新資源，關於資源實體的內容，一般放在請求體（Request Body）中。
實際傳送請求，還需要有動詞，表示對該資源執行什麼樣的操作。那麼超出這個範圍的操作該如何擴充套件？
REST操作返回什麼內容？對於刪除、新增、更新等操作，通常是返回操作是否成功的標識；如果失敗，需要返回錯誤程式碼和訊息，方便客戶端做進一步處理。如果是查詢操作，通常包含實體或者實體列表。
在最佳實踐中，應當還應該返回與此操作相關的其他操作。比如，查詢得到實體的響應中，應包含該實體的刪除、更新操作的地址。
請求和返回的Body，採用什麼格式？常見的格式包括XML/JSON/HTML。
說法四
持續整理中… …