rest越來越流行，感覺挺高大尚的。網上看了很多網友的說法，各有各的看法，我覺得很多說得很有道理。
說法一
restful風格，就是一種面向資源服務的API設計方式，它不是規範，不是標準，它一種設計模式。以前流行的web service服務都是面向過程，基於RPC協議的SOAP協議，對於現在或者未來，更多的人了解並且深受SOA思想影響，以面向服務為目標，而現在的SOAP雖然支持SOA，但存在很很大的差別，所以，慢慢就流行基於restful風格的web service。說簡單一點，就是它純粹面向資源，面向服務的思想，目前J2EE6的JAX-RS就是這種restful風格實現的新技術。
說法二

阮一峰的那篇文章我認為沒有講到實質，他能讓人大概知道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.批量的刪除、修改、新增如何滿足

說法三
作者：Tony
鏈接：http://www.zhihu.com/question/33959971/answer/58671683
來源：知乎
著作權歸作者所有。商業轉載請聯系作者獲得授權，非商業轉載請註明出處。

應題主要求，簡要回答它的優勢或優點。
首先，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。

說法四
持續整理中… …

個人傾向於：說法三，跟我目前的項目中的設計方式比較吻合

　　　　　　　　　　　　　　　　　　　　　　　　　　　　——caogen1991

文章轉自：https://blog.csdn.net/programmer_sir/article/details/51592433

Restful風格到底是什麽？怎麽應用到我們的項目中？