在介紹restful之前先放一張從之前文章評論里看到的圖，我覺得它把soap和rest之間的一些區別形容地非常形象。 在第一篇和第二篇中我們也介紹過，soap協議傳遞的報文要基於xml格式的soap消息，它定義了非常複雜的xml schemas，因此會讓傳遞的消息變得非常重，而rest是充分利用了h ...
在介紹restful之前先放一張從之前文章評論里看到的圖，我覺得它把soap和rest之間的一些區別形容地非常形象。
在第一篇和第二篇中我們也介紹過，soap協議傳遞的報文要基於xml格式的soap消息，它定義了非常複雜的xml schemas，因此會讓傳遞的消息變得非常重，而rest是充分利用了http協議本身語義，所以會比較輕量。那麼除了這些，rest和我們常用的soap協議又有那些區別呢？rest為什麼會被看成是未來webservice的發展趨勢？下麵就讓我們具體來看看什麼是rest，什麼是restful webservcie。
1.概述REST和RESTful
REST全稱是Representational State Transfer，中文意思是表徵性狀態轉移。 它首次出現在2000年Roy Fielding的博士論文中，Roy Fielding是HTTP規範的主要編寫者之一。 他在論文中提到："我這篇文章的寫作目的，就是想在符合架構原理的前提下，理解和評估以網路為基礎的應用軟體的架構設計，得到一個功能強、性能好、適宜通信的架構。REST指的是一組架構約束條件和原則。" 如果一個架構符合REST的約束條件和原則，我們就稱它為RESTful架構。
REST本身並沒有創造新的技術、組件或服務，而隱藏在RESTful背後的理念就是使用Web的現有特征和能力， 更好地使用現有Web標準中的一些準則和約束。雖然REST本身受Web技術的影響很深， 但是理論上REST架構風格並不是綁定在HTTP上，只不過目前HTTP是唯一與REST相關的實例。
是不是被上面一段話整的雲里霧裡？其實用人話來總結就是：
- REST是一種風格是用URL定位資源，用HTTP動詞（GET,POST,DELETE,PUT,PATCH ）描述操作的協議。
- RESTful實現REST風格的一種軟體架構風格，提供了設計原則和約束條件。
2.理解REST
2.1 資源
REST全稱是表徵性狀態轉移，表徵指的就是資源。任何事物，只要有被引用到的必要，它就是一個資源。資源可以是實體(例如手機號碼)，也可以只是一個抽象概念(例如價值) 。下麵是一些資源的例子：
- 某用戶的手機號碼
- 某用戶的個人信息
- 最多用戶訂購的GPRS套餐
- 兩個產品之間的依賴關係
- 某用戶可以辦理的優惠套餐
- 某手機號碼的潛在價值
2.1.1資源的標識
要讓一個資源可以被識別，需要有個唯一標識，在Web中這個唯一標識就是URI(Uniform Resource Identifier)。
URI既可以看成是資源的地址，也可以看成是資源的名稱。如果某些信息沒有使用URI來表示，那它就不能算是一個資源， 只能算是資源的一些信息而已。URI的設計應該遵循可定址性原則，具有自描述性，需要在形式上給人以直覺上的關聯。這裡以github網站為例，給出一些還算不錯的URI：
2.1.2 統一資源介面
RESTful架構應該遵循統一介面原則，統一介面包含了一組受限的預定義的操作，不論什麼樣的資源，都是通過使用相同的介面進行資源的訪問。介面應該使用標準的HTTP方法如GET，PUT和POST，並遵循這些方法的語義。
如果按照HTTP方法的語義來暴露資源，那麼介面將會擁有安全性和冪等性的特性，例如
- GET和HEAD請求都是安全的，無論請求多少次，都不會改變伺服器狀態。
- GET、HEAD、PUT和DELETE請求都是冪等的，無論對資源操作多少次，結果總是一樣的，後面的請求並不會產生比第一次更多的影響。
GET /zoos：列出所有動物園
POST /zoos：新建一個動物園
GET /zoos/ID：獲取某個指定動物園的信息
PUT /zoos/ID：更新某個指定動物園的信息（提供該動物園的全部信息）
PATCH /zoos/ID：更新某個指定動物園的信息（提供該動物園的部分信息）
DELETE /zoos/ID：刪除某個動物園
GET /zoos/ID/animals：列出某個指定動物園的所有動物
DELETE /zoos/ID/animals/ID：刪除某個指定動物園的指定動物
REST的發明者Roy Fielding博士曾經說過“Hypermedia作為應用引擎”是REST的前提， 這不是一個可選項，如果沒有Hypermedia，那就不是REST。(摘自Infoq對Fielding博士的第二段訪談）
因此除了符合HTTP協議自身的語義，REST還要滿足Hypermedia（超媒體即應用狀態引擎（hypermedia as the engine of application state））。
採用Hypermedia的API在響應（response）中除了返回資源（resource）本身外，還會額外返回一組鏈接（link）。 這組鏈接描述了對於該資源，消費者（consumer）接下來可以做什麼以及怎麼做。
這樣做的好處是：
1. 不再揣測如何組合使用API
2. 不用再考慮API的版本
3. 徹底與API的內部實現解耦在這裡分享一篇詳細介紹Hypermedia的文章，寫得很好，有興趣的同學可以點進去瞭解下。
http://hippoom.github.io/blogs/value-of-hypermedia-from-client-perspective.html
2.1.3資源的表述
客戶端通過HTTP可以獲取資源，這個資源一般只是資源的表述。 例如文本資源可以採用html、xml、json等格式，圖片可以使用PNG或JPG展現出來
2.2 無狀態
“會話”狀態不是作為資源狀態保存在服務端的，而是被客戶端作為應用狀態進行跟蹤的。即RESTful 服務是無狀態的並且不會為任何客戶端保持狀態。一個請求不應該依賴過去的請求，服務對待每個請求都是獨立的。客戶端應用狀態在服務端提供的超鏈接的指引下發生變遷。服務端通過超鏈接告訴客戶端當前狀態有哪些後續狀態可以進入。
舉個慄子，假設我們在閱讀一篇需要翻頁的文章，我們如果要訪問下一頁。
有狀態的請求就需要記錄我們上一次請求的頁數PageNo，然後根據PageNo請求下一頁
有狀態設計：
Request1: GET http://MyService/Page/1
Request2: GET http://MyService/NextPage Request2的請求是要基於Request1請求的頁數來進行的，伺服器需要記住這個頁數，否則Request2無法進行。即Request2需要依賴Request1操作，如果Request1操作不成功，則Request2也不會成功。
而無狀態設計中每一步都是獨立，我們請求任何一頁都不需要知道上一次請求的是哪一頁。
無狀態設計像這樣：
Request1: GET http://MyService/Page/1
Request2: GET http://MyService/Page/2
每個請求都能被單獨對待。
無狀態服務更容易設計成集群，更容易維護，更容易伸縮。這樣的服務提供了更好的響應時間，因為它們能容易進行負載均衡。隨著微服務的概念越來越普及，無狀態設計勢必會成為未來的趨勢。
綜上，我們總結下REST的要求：
- 客戶端和伺服器結構 通信只能由客戶端單方面發起，表現為請求-響應的形式。
- 連接協議具有無狀態性
通信的會話狀態（Session State）應該全部由客戶端負責維護。 - 能夠利用Cache（緩存）機制增進性能
伺服器返回信息必須被標記是否可以緩存，如果緩存，客戶端可能會重用之前的信息發送請求。 - 統一介面（Uniform Interface）
- 層次化的系統
系統組件不需要知道與他交流組件之外的事情。封裝服務，引入中間層。 - 按需代碼（Code-On-Demand ） - Javascript （可選）
泛指任何按照客戶端軟體（例如，瀏覽器）的請求，將可執行的軟體程式從伺服器電腦發送到客戶端的技術。
3.怎麼評價REST
3.1 REST優勢
- 輕量，直接基於http，不在需要任何別的諸如消息協議。get/post/put/delete為CRUD（增刪改查）操作，充分利用 HTTP 協議本身語義。
- 客戶-伺服器（Client-Server）客戶端伺服器分離，提高用戶界面的便攜性（操作簡單），通過簡化伺服器提高可伸縮性（高性能，低成本），允許組件分別優化（可以讓服務端和客戶端分別進行改進和優化）
- 無狀態（Stateless），從客戶端的每個請求要包含伺服器所需要的所有信息。
- 提高可見性（可以單獨考慮每個請求）
- 提高了可靠性（更容易從局部故障中修複）
- 提高可擴展性（降低了伺服器資源使用）
- HTTP 本身提供了豐富的內容協商手段，無論是緩存，還是資源修改的樂觀併發控制，都可以以業務無關的中間件來實現，限制了系統的複雜性，提高了可擴展性。
3.2 RESR缺點
- restful首先是要求必須把所有的應用定義成為“resource”，然後只能針對資源做有限的四種操作（即增刪改查）。有許多現實中需要的API無法融入到restful所定義的規範中，比如user login / resetpassword等。雖然可以把login / password等也納入為某種資源，然後進行增刪改查。但這是在解決一些原本不存在不需要解決的問題，純屬浪費。 restful API僅適用與業務非常簡單的場景，比方說，就是為了提供少量數據表單的增刪改查。而這種場景實在是太過簡單，實際中幾乎找不到。所有的介面，伺服器端原本就存在有相應的函數，它們本來就有自身的命名空間，接受的參數、返回值、異常等等。
採用輕便的方式暴露出來即可。無需把一堆函數重新歸納到“資源”，再削減腦袋把所有的操作都映射為“增刪改查”。 - 開發效率低【不適應於自動化處理】
- 運行效率低【需要比較複雜的字元串匹配模式】
- 環境適應性差【不適應參數複雜的情況】
4.RESTful的應用
- 亞馬遜提供rest風格的介面查找圖書
- 雅虎提供的Web Service也是REST風格的
