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

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

源於REST之父 Roy Thomas Fielding 2000年的一篇博士論文。
Fielding是一個非常重要的人，他是HTTP協議（1.0版和1.1版）的主要設計者、Apache伺服器軟體的作者之一、Apache基金會的第一任主席。
所以，他的這篇論文一經發表，就引起了關注，並且立即對網際網路開發產生了深遠的影響。
翻譯論文一段：”我這篇文章的寫作目的，就是想在符合架構原理的前提下，理解和評估以網路為基礎的應用軟體的架構設計，得到一個功能強、效能好、適宜通訊的架構。”

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
  比如資源的內容和格式都可以看做狀態。
  如果客戶端想要操作伺服器，必須通過某種手段，讓伺服器端發生”狀態轉化”（State Transfer）。而這種轉化是建立在表現層之上的，
  所以就是”表現層狀態轉化”。

客戶端用到的手段，只能是HTTP協議。具體來說，就是HTTP協議裡面，四個表示操作方式的動詞：GET、POST、PUT、DELETE。
它們分別對應四種基本操作：GET用來獲取資源，POST用來新建資源（也可以用於更新資源），PUT用來更新資源，DELETE用來刪除資源。

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

(1)客戶-伺服器（Client-Server）
通訊只能由客戶端單方面發起，表現為請求-響應的形式。

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

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

(4)統一介面（Uniform Interface）
通訊鏈的元件之間通過統一的介面相互通訊，以提高互動的可見性。

(5)分層系統（Layered System）
通過限制元件的行為（即，每個元件只能“看到”與其互動的緊鄰層），將架構分解為若干等級的層。

(6)按需程式碼（Code-On-Demand，可選）
支援通過下載並執行一些程式碼（例如Java Applet、Flash或JavaScript），對客戶端的功能進行擴充套件。

4:RestFul架構的優點：
結構清晰、符合標準、易於理解、擴充套件方便。
使異構系統間的通訊變得簡單
鬆耦合
易於測試：
（1）瀏覽器即可作為客戶端,還可以藉助火狐的外掛RestClient。
（2）可以使用Apache的Jemeter。
（3）使用 curl命令列工具

RESTful 的設計方式降低了資源物件設計的自由度，本來你要同時設計物件的狀態資料和關聯的行為，不太好控制。
而 REST 把 url 裡的動詞都去掉了，資源物件只剩下有限的幾種行為，這樣不同的人更容易設計出差不多的東西，
別人看你設計的東西，需要的解釋也更少。

簡單性
採用REST架構風格，對於開發、測試、運維人員來說，都會更簡單。可以充分利用大量HTTP伺服器端和客戶端開發庫、Web功能測試/效能測試工具、HTTP
快取、HTTP代理伺服器、防火牆。這些開發庫和基礎設施早已成為了日常用品，不需要什麼火箭科技（例如神奇昂貴的應用伺服器、中介軟體）就能解決大多數可
伸縮性方面的問題。

可伸縮性
充分利用好通訊鏈各個位置的HTTP快取元件，可以帶來更好的可伸縮性。其實很多時候，在Web前端做效能優化，產生的效果不亞於僅僅在伺服器端做效能優化，
但是HTTP協議層面的快取常常被一些資深的架構師完全忽略掉。

鬆耦合
統一介面+超文字驅動，帶來了最大限度的鬆耦合。允許伺服器端和客戶端程式在很大範圍內，相對獨立地進化。對於設計面向企業內網的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）:伺服器返回的資料格式，應該儘量使用JSON，避免使用XML。

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

7：如何單元測試
（1）：瀏覽器位址列（GET）
（2）:火狐的RestClient
（3）:Jmeter
（4）:Curl命令列工具

———————————————————————————————————————
我開通了微信訂閱號“i小窩”，關注即可第一時間看到我的原創文章以及我推薦的精彩文章：