我對REST的理解

1:rest的由來
REST即表述性狀態傳遞（英文：Representational State Transfer，簡稱REST）

通俗點說：資源在網絡中以某種表現形式進行狀態轉移。

源於REST之父 Roy Thomas Fielding 2000年的一篇博士論文。
Fielding是一個很是重要的人。他是HTTP協議（1.0版和1.1版）的主要設計者、Apacheserver軟件的做者之中的一個、Apache基金會的第一任主席。
因此。他的這篇論文一經發表，就引發了關注，而且立刻對互聯網開發產生了深遠的影響。

翻譯論文一段：」我這篇文章的寫做目的，就是想在符合架構原理的前提下，理解和評估以網絡爲基礎的應用軟件的架構設計。獲得一個功能強、性能好、適宜通訊的架構。」

論文地址：
Architectural Styles and the Design of Network-based Software Architectures
http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm

REST章節：
Fielding Dissertation: CHAPTER 5: Representational State Transfer (REST)
http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm

REST產生的背景？
你們都知道」古代」網頁都是前端後端融在一塊兒的。比方以前的PHP，JSP等。在以前的桌面時代問題不大，
但是近年來移動互聯網的發展，各類類型的Client層出不窮，RESTful可以經過一套統一的接口爲 Web。iOS和Android提供服務。

另外對於廣大平臺來講。比方Facebook platform。微博開放平臺。微信公共平臺等，它們不需要有顯式的前端，僅僅需要一套提供服務的接口，
因而RESTful更是它們最好的選擇。

2:細說Rest(Representational State Transfer）
REST 一種軟件架構風格，設計風格而不是標準，僅僅是提供了一組設計原則和約束條件。
知足這些約束條件和原則的應用程序或設計就是 RESTful。

• Representational
  「表現層」省略了主語。事實上指的是」資源」（Resources）的」表現層」。
  「資源」。就是網絡上的一個實體，或者說是網絡上的一個詳細信息。它可以是一段文本、一張圖片、一首歌曲、一種服務。總之就是一個詳細的實在。
  你可以用一個URI（統一資源定位符）指向它，每種資源相應一個特定的URI。要獲取這個資源，訪問它的URI就可以，所以URI就成了每一個資源
  的地址或獨一無二的識別符。

「資源」是一種信息實體，它可以有多種外在表現形式。咱們把」資源」詳細呈現出來的形式。叫作它的」表現層」（Representation）。
比方，文本可以用txt格式表現。也可以用HTML格式、XML格式、JSON格式表現，甚至可以採用二進制格式。圖片可以用JPG格式表現，也可以用PNG格式表現。

• State Transfer
  比方資源的內容和格式都可以看作狀態。

  
  假設client想要操做server，必須經過某種手段。讓server端發生」狀態轉化」（State Transfer）。

  而這樣的轉化是創建在表現層之上的。
  因此就是」表現層狀態轉化」。

client用到的手段，僅僅能是HTTP協議。詳細來講。就是HTTP協議裏面，四個表示操做方式的動詞：GET、POST、PUT、DELETE。
它們分別相應四種基本操做：GET用來獲取資源，POST用來新建資源（也可以用於更新資源）。PUT用來更新資源。DELETE用來刪除資源。

3:REST架構風格的架構約束：

(1)客戶-server（Client-Server）
通訊僅僅能由client單方面發起，表現爲請求-響應的形式。

(2)無狀態（Stateless）
通訊的會話狀態（Session State）應該全部由client負責維護。

(3)緩存（Cache）
響應內容可以在通訊鏈的某處被緩存，以改善網絡效率。

(4)統一接口（Uniform Interface）
通訊鏈的組件之間經過統一的接口相互通訊。以提升交互的可見性。

(5)分層系統（Layered System）
經過限制組件的行爲（即，每一個組件僅僅能「看到」與其交互的緊鄰層），將架構分解爲若干等級的層。

(6)按需代碼（Code-On-Demand。可選）
支持經過下載並運行一些代碼（好比Java Applet、Flash或JavaScript）。對client的功能進行擴展。

4:RestFul架構的長處：
結構清晰、符合標準、易於理解、擴展方便。

使異構系統間的通訊變得簡單
鬆耦合
易於測試：
（1）瀏覽器就能夠做爲client,還可以藉助火狐的插件RestClient。
（2）可以使用Apache的Jemeter。
（3）使用 curl命令行工具

RESTful 的設計方式減小了資源對象設計的自由度。原本你要同一時候設計對象的狀態數據和關聯的行爲，不太好控制。
而 REST 把 url 裏的動詞都去掉了，資源對象僅僅剩下有限的幾種行爲，這樣不一樣的人更easy設計出差點兒相同的東西。
別人看你設計的東西，需要的解釋也更少。

簡單性
採用REST架構風格，對於開發、測試、運維人員來講。都會更簡單。可以充分利用大量HTTPserver端和client開發庫、Web功能測試/性能測試工具、HTTP
緩存、HTTP代理server、防火牆。這些開發庫和基礎設施早已成爲了日常用品，不需要什麼火箭科技（好比奇妙昂貴的應用server、中間件）就能解決大多數可
伸縮性方面的問題。

可伸縮性
充分利用好通訊鏈各個位置的HTTP緩存組件。可以帶來更好的可伸縮性。事實上很是多時候，在Web前端作性能優化，產生的效果不亞於僅僅在server端作性能優化，
但是HTTP協議層面的緩存常常被一些資深的架構師全然忽略掉。

鬆耦合
統一接口+超文本驅動。帶來了最大限度的鬆耦合。

贊成server端和client程序在很是大範圍內。相對獨立地進化。對於設計面向企業內網的API來講，鬆耦合並不
是一個很是重要的設計關注點。但是對於設計面向互聯網的API來講，鬆耦合變成了一個必選項，不只在設計時應該關注。而且應該放在最優先位置。

5：REST與Jersey和JAX-RS的關係
Rest是一種架構風格。
Jersey是對JAX-RS的一種實現。

JAX-RS（Java API for RESTful Web Services）是一套用java實現REST服務的規範

6:URL設計
糟糕的設計：
/getProducts
/createProducts
/getProducts?proId=4
/updayeProduct?proId=4
/deleteProduct?proId=4

優雅的設計
GET /products
POST /products
GET /products/4
PUT /products/4
DELETE /products/4

注意什麼？
（1）：URI使用名詞而不是動詞，且推薦用複數。

（2）：一個URI標識一個資源，但是一個資源可以被多個URI標識。

（3）：資源也是有層次的。這個層次應該在URI上充分的體現出來。

GET /cars/711/drivers/ 返回 car 711的全部司機

GET /cars/711/drivers/4 返回 car 711的4號司機

（4）：需要有一個URI定義的文檔，以備之後的查詢和維護。

（5）：合理使用http狀態碼

（6）：規範返回結果格式
{
errorCode: 「401」,
errorMsg: 「Unauthorized」
data :data

}
（7）:server返回的數據格式，應該儘可能使用JSON。避免使用XML。

總之：
看URL就知道要什麼
看Http method就知道要幹什麼
和Http status code就知道結果怎樣

7：怎樣單元測試
（1）：瀏覽器地址欄（GET）
（2）:火狐的RestClient
（3）:Jmeter
（4）:Curl命令行工具

參考文檔：
http://www.ruanyifeng.com/blog/2011/09/restful.html
http://blog.csdn.net/column/details/restful.html

———————————————————————————————————————
我開通了微信訂閱號「i小窩」，關注就能夠第一時間看到個人原創文章以及我推薦的精彩文章：