REST Web 服務（一）----REST 介紹

1. 什麼是REST？

REST 定義了一組體系架構原則，您能夠根據這些原則設計以系統資源爲中心的 Web 服務，包括使用不一樣語言編寫的客戶端如何經過 HTTP 處理和傳輸資源狀態。

2. REST的架構原則？

其具體實現應該遵循四個基本設計原則：

1)顯式地使用 HTTP 方法。

2)無狀態通訊。

3)公開目錄結構式的 URI。

4)傳輸 XML、JavaScript Object Notation (JSON)，或同時傳輸這二者。

關於REST原則的詳細內容見：基於 REST 的 Web 服務：基礎

深刻淺出REST

3. REST特色

REST (REpresentational State Transfort) 形式上應該表述爲客戶端經過申請資源來實現狀態的轉換，在這個角度系統能夠當作一臺虛擬的狀態機。REST應該知足這樣的特色：

1)客戶端和服務器結構；

2)鏈接協議具備無狀態性；

無狀態性是在客戶－服務器約束的基礎上添加的又一層規範。他要求通訊必須在本質上是無狀態的，即從客戶到服務器的每一個request都必須包含理解該 request所必須的全部信息。這個規範改善了系統的可見性（無狀態性使得客戶端和服務器端沒必要保存對方的詳細信息，服務器只須要處理當前 request，而沒必要了解全部的request歷史），可靠性（無狀態性減小了服務器從局部錯誤中恢復的任務量），可伸縮性（無狀態性使得服務器端能夠 很容易的釋放資源，由於服務器端沒必要在多個request中保存狀態）。

3)可以利用Cache機制增進性能；

爲了改善無狀態性帶來的網絡的低效性，咱們填加了緩存約束。緩存約束容許隱式或顯式地標記一個response中的數據，這樣就賦予了客戶端緩存 response數據的功能，這樣就能夠爲之後的request共用緩存的數據，部分或所有的消除一部分交互，增長了網絡的效率。

4)層次化的系統；

分層系統規則的加入提升了各類層次之間的獨立性，爲整個系統的複雜性設置了邊界，經過封裝遺留的服務，使新的服務器免受遺留客戶端的影響，這也就提升了系統的可伸縮性。

5)按需代碼。

REST容許對客戶端功能進行擴展。好比，經過下載並執行applet或腳本形式的代碼，來擴展客戶端功能。但這在改善系統可擴展性的同時，也下降了可見性。因此它只是REST的一個可選的約束。

4. REST與SOAP的區別

1）SOAP WS支持既遠程過程調用（例如，RPC）又支持消息中間件（MOM）方式進行應用集成。而Restful Web Service僅支持RPC集成方式。

2）SOAP WS是傳輸協議無關的。它支持多種協議，好比，HTTP(S)、 Messaging、TCP、UDP SMTP等等。而REST是協議相關的，只支持HTTP或者HTTPS協議。

3）SOAP WS僅容許使用XML數據格式。定義的操做經過POST請求發送。其重點是經過操做名來獲取服務，並將應用邏輯封裝爲服務。而REST方式則容許多種數據格式，例如，XML、JSON、文本、HTML等等。並且因爲REST方式採用標準GET、PUT、PSOT和DELETE 方法，所以全部的瀏覽器均可以支持。其重點是經過資源名來獲取服務，並將數據封裝爲服務。AJAX支持REST方式，它可使用 XMLHttpRequest對象。無狀態CRUD操做（建立、讀、更新和刪除）更加適合這種方式。

GET – represent()

POST – acceptRepresention()

PUT – storeRepresention()

DELETE – removeRepresention()

4）沒法緩存SOAP方式讀取的內容。而REST方式的則能夠，並且性能和可擴展性都更好一些。 SOAP WS支持SSL和WS-security，針對企業級應用能夠有更多的安全保障，例如按需提高安全指數、經過第三方來保證身份認證信息的安全性、除了點到點SSL（point to point SSL）以外，更針對消息的不一樣部分來提供不一樣的保密算法等等。而REST只支持點到點SSL。並且不管是否是敏感消息，SSL都會加密整條消息。

5）SOAP對於基於ACID的短壽命事務管理以及基於補償事務管理的長壽命事務有深刻的支持。同時，SOAP也支持分佈式事務（譯者：在一個分佈式環境中涉及到多個資源管理器的事務）的兩階段提交（two-phase commit）方式。而REST因爲基於HTTP協議，所以對於事務處理既不兼容ACID方式也不提供分佈式事務的兩階段提交方式。

6）即使是要經過SOAP的第三方程序，SOAP經過內置的重試邏輯也能夠提供端到端可靠性。REST沒有一個標準的消息系統，於是寄但願於客戶經過重連去解決通訊失敗問題。

5. RESTful架構有一些典型的設計誤區

最多見的一種設計錯誤，就是URI包含動詞。由於"資源"表示一種實體，因此應該是名詞，URI不該該有動詞，動詞應該放在HTTP協議中。 舉例來講，某個URI是/posts/show/1，其中show是動詞，這個URI就設計錯了，正確的寫法應該是/posts/1，而後用GET方法表示show。 若是某些動做是HTTP動詞表示不了的，你就應該把動做作成一種資源。好比網上匯款，從帳戶1向帳戶2匯款500元，錯誤的URI是：

POST /accounts/1/transfer/500/to/2

正確的寫法是把動詞transfer改爲名詞transaction，資源不能是動詞，可是能夠是一種服務：

POST /transaction HTTP/1.1

Host: 127.0.0.1

from=1&to=2&amount=500.00

另外一個設計誤區，就是在URI中加入版本號：

http://www.example.com/app/1.0/foo

http://www.example.com/app/1.1/foo

http://www.example.com/app/2.0/foo

由於不一樣的版本，能夠理解成同一種資源的不一樣表現形式，因此應該採用同一個URI。版本號能夠在HTTP請求頭信息的Accept字段中進行區分（參見Versioning REST Services）：

Accept: vnd.example-com.foo+json; version=1.0

Accept: vnd.example-com.foo+json; version=1.1

Accept: vnd.example-com.foo+json; version=2.0

6. RESTful API設計原則？

1）每一個實體對象僅須要兩個URL

/books # for Collections

/books/2 # for Single Object

每一個對象僅須要兩個url，第一個是獲取對象的集合，第二個是獲取單個對象

2）使用名詞代替動詞

/books/2 # Good :)

/getBook?id=2 # Bad :(

3）正確使用HTTP方法

GET # Read

POST # Create

PUT # Update

DELETE # Delete

4）對象間的關聯關係

/books/2/author # book author

/author/1/books # author's books

5）數據分頁

/books?start=10&count=20 # return the books from 10 to 30

6）查詢條件

/books?order=hot # return the books order by hot

7）返回須要的參數

/books/2?fields=author,isbn,price # only return the book's author, isbn and price

8）錯誤處理

依靠status code來給程序標識錯誤，常見的status code以下：

200 - OK # GET success

201 - CREATED # POST success

202 - ACCEPTED # PUT success

400 - BAD REQUEST # Wrong path or unsupported parameters

401 - UNAUTHORIZED # Need Authorize

403 - FORBIDDEN # forbidden to access

404 - NOT FOUND # Resource not exists

500 - INTERNAL ERROR # Server error

具體的錯誤信息和錯誤代碼（自定義的錯誤代碼）也要返回：

{"code": 1000, "message": "missing_args", "request": "GET /books/2"}