第三篇：RESTful介紹

在介紹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：

• https://github.com/git
• https://github.com/git/git
• https://github.com/git/git/blob/master/block-sha1/sha1.h
• https://github.com/git/git/pulls
• https://github.com/git/git/pulls?state=closed
• https://github.com/git/git/compare/master…next

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的要求：

1. 客戶端和服務器結構 通訊只能由客戶端單方面發起，表現爲請求-響應的形式。
2. 鏈接協議具備無狀態性
   通訊的會話狀態（Session State）應該所有由客戶端負責維護。
3. 可以利用Cache（緩存）機制增進性能
   服務器返回信息必須被標記是否能夠緩存，若是緩存，客戶端可能會重用以前的信息發送請求。
4. 統一接口（Uniform Interface）
5. 層次化的系統
   系統組件不須要知道與他交流組件以外的事情。封裝服務，引入中間層。
6. 按需代碼（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風格的