REST風格的軟體架構

標籤：android   style   http   color   io   os   ar   使用   for   

如果一個網站不是 REST 風格架構，肯會被程式員鄙視一番！

移動互連網的飛速發展，特別是移動互連網，給開發人員帶來了新的機遇和挑戰。手機端除了app，我們還會經常接觸到移動web，除了瀏覽器中，很多app裡面也會使用web服務，我們會在手機上面做更多複雜的操作，老一代的系統架構已經不再適應了，需要更加規範和優秀的軟體架構來應對今天的挑戰，那就是 REST 。

從 HTTP 協議說起

首先的熟悉一個概念 URI，Web上可用的每種資源 -HTML文檔、映像、視頻片段、程式等 - 由一個通用資源標識符（Uniform Resource Identifier, 簡稱"URI"）進行定位。
例如：http://www.bigertech.com/a.jpg

Http協議定義了用戶端與伺服器互動的不同方法，最基本的方法有4種，分別是GET，POST，PUT，DELETE

• 若要在伺服器上建立資源，應該使用 POST 方法。
• 若要檢索某個資源，應該使用 GET 方法。
• 若要更改資源狀態或對其進行更新，應該使用 PUT 方法。
• 若要刪除某個資源，應該使用 DELETE 方法。

資源多重表述 
針對不同的需求提供資源多重表述。這裡所說的多重表述包括XML、JSON、HTML等。即伺服器端需要向外部提供多種格式的資源表述，供不同的用戶端使用。比如行動裝置 App可以使用XML或JSON和伺服器端通訊，而瀏覽器則能夠理解HTML。

注意：HTTP規範中中，GET用於資訊擷取，而且應該是安全的和等冪的

實際開發中很多人違背了這個協議

• 很多人貪方便，嫌 POST 使用表單的麻煩，更新資源時用了GET
• 對資源的增，刪，改，查操作，其實都可以通過GET/POST完成，不需要用到PUT和DELETE。
• 另外一個是，早期的但是Web MVC架構設計者們並沒有有意識地將URL當作抽象的資源來看待和設計 。還有一個較為嚴重的問題是傳統的Web MVC架構基本上都只支援GET和POST兩種HTTP方法，而不支援PUT和DELETE方法。

所以新的一套支援HTTP 軟體架構風格出現了。

什麼是REST

REST (Representational state transfer）,表徵狀態轉義。是 Roy Fielding 博士在2000年他的博士論文中提出來的一種 軟體架構 風格。

越來越多的服務使用這種軟體架構來設計和實現，例如：Amazon.com提供接近REST風格的Web服務進行圖書尋找；雅虎提供的Web服務也是REST風格的。

** 值得注意的是，REST是設計風格而不是標準。而是通過表徵（Representional ）來描述傳輸狀態的一種原則。其宗旨是從資源的角度來觀察整個網路，分布在各處的資源由URI確定，而用戶端的應用通過URI來擷取資源的表徵。獲得這些表徵致使這些應用程式轉變了其狀態。隨著不斷擷取資源的表徵，用戶端應用不斷地在轉變著其狀態。

REST軟體架構使用了CRUD原則，該原則告訴我們對於資源（包括網路資源）只需要四種行為：建立（Create）、擷取（Read）、更新（Update）和銷毀（DELETE），就可以組合成其他無數的操作。其實世界萬物都是遵循這一規律：生、變、見、滅。這個原則是源自於我們對於資料庫表的資料操作：insert（生）、select（見）、update（變）和delete（滅），所以有時候CRUD也寫作為RUDI（read update delete insert）。這四個操作是最基本的操作，即無法再細分的操作，通過它們可以構造複雜的操作過程，正如數學上四則運算是數位最基本的運算一樣。

REST的要求

• 用戶端和伺服器結構
• 連線協定具有無狀態性
• 能夠利用Cache機制增進效能
• 層次化的系統

關於狀態

應該注意區別應用的狀態和連線協定的狀態。HTTP串連是無狀態的（也就是不記錄每個串連的資訊），而REST傳輸會包含應用的所有狀態資訊，因此可以大幅降低對HTTP串連的重複請求資源消耗。

含狀態傳輸的 Web 服務

含狀態傳輸的 Web 服務（也稱為 RESTful Web API）是一個使用HTTP並遵循REST原則的Web服務。它從以下三個方面資源進行定義：

1. 直觀簡短的資源地址：URI，比如：http://example.com/resources/。
2. 傳輸的資源：Web服務接受與返回的互連網媒體類型，比如：JSON，XML ，YAML 等。
3. 對資源的操作：Web服務在該資源上所支援的一系列要求方法（比如：POST，GET，PUT或DELETE）。
   PUT 和 DELETE 方法是等冪方法。GET方法是安全方法 （不會對伺服器端有修改，因此當然也是等冪的）。等冪的意味著對同一URL的多個請求應該返回同樣的結果。比如絕對值運算就是一個例子，在實數集中，有abs(a) = abs(abs(a)) 。

REST的實現

各大用戶端和伺服器端都 REST 的風格架構都有相應的實現，包括 android、IOS 、web端

web端

jquery的ajax 函數

$.ajax({            type: ‘PUT‘,   //options GET、POST、DELETE          url: this.myurl,       });

nodejs

• express 4.x 版本內建了 rest 的路由
• node-restify
• restler 用戶端使用rest

REST和AJAX

在Ajax出現以前，瀏覽器的功能相對比較弱，只能實現一些瘦用戶端的功能，因此，Web應用的開發人員們只能把功能的實現盡量向伺服器端移，這樣產生了現在被廣泛使用的WebMVC架構模式。這樣做，其實有很多地方已經違反了REST的架構約束，但在當時是沒有辦法的Ajax出現後，瀏覽器的能力大大增強了，這時依靠Ajax的能力真的有可能完全遵從REST的架構約束了，這就需要把許多功能前移，建造更強大的用戶端了。這也許就是為什麼REST會隨著Ajax的出現而漸漸流行開來的原因，當然，Rails DHH的大力推廣也有功不可沒。

REST的優點

• 可更高效利用緩衝來提高響應速度
• 通訊本身的無狀態性可以讓不同的伺服器的處理一系列請求中的不同請求，提高伺服器的擴充性
• 瀏覽器即可作為用戶端，簡化軟體需求
• 相對於其他疊加在HTTP協議之上的機制，REST的軟體依賴性更小
• 不需要額外的資摘要搜索機制
• 在軟體技術演化中的長期的相容性更好

眾所周知，對於基於網路的分布式應用，網路傳輸是一個影響應用效能的重要因素。如何使用緩衝來節省網路傳輸帶來的開銷，這是每一個構建分布式網路應用的開發人員必須考慮的問題。

HTTP 協議帶條件的 HTTP GET 請求 (Conditional GET) 被設計用來節省用戶端與伺服器之間網路傳輸帶來的開銷，這也給用戶端實現 Cache 機制 ( 包括在用戶端與伺服器之間的任何代理 ) 提供了可能。HTTP 協議通過 HTTP HEADER 域：If-Modified-Since/Last- Modified，If-None-Match/ETag 實現帶條件的 GET 請求。

REST 的應用可以充分地挖掘 HTTP 協議對緩衝支援的能力。當用戶端第一次發送 HTTP GET 請求給伺服器獲得內容後，該內容可能被快取服務器 (Cache Server) 緩衝。當下一次用戶端請求同樣的資源時，緩衝可以直接給出響應，而不需要請求遠端伺服器獲得。而這一切對用戶端來說都是透明的。

REST風格的軟體架構