如果一個網站不是 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等。即服務器端需要向外部提供多種格式的資源表述，供不同的客戶端使用。比如移動應用可以使用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服務。它從以下三個方面資源進行定義：
- 直觀簡短的資源地址：URI，比如：
http://example.com/resources/。 - 傳輸的資源：Web服務接受與返回的互聯網媒體類型，比如：JSON，XML ，YAML 等。
- 對資源的操作：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) 緩存。當下一次客戶端請求同樣的資源時，緩存可以直接給出響應，而不需要請求遠程的服務器獲得。而這一切對客戶端來說都是透明的。