論REST架構與傳統MVC
阿新 • • 發佈：2017-08-30
ftw 處理 put 優化 interface 聯網 參數 優點 out
這種規範的提出，改善了用戶接口跨多個平臺的可移植性，並且通過簡化服務器組件，改善了系統的可伸縮性。最為關鍵的是通過分離用戶接口和數據存儲這兩個關註點，使得不同用戶終端享受相同數據成為了可能。
（2）無狀態性
無狀態性是在客戶－服務器約束的基礎上添加的又一層規範。他要求通信必須在本質上是無狀態的，即從客戶到服務器的每個request都必須包含理解該 request所必須的所有信息。這個規範改善了系統的可見性（無狀態性使得客戶端和服務器端不必保存對方的詳細信息，服務器只需要處理當前 request，而不必了解所有的request歷史），可靠性（無狀態性減少了服務器從局部錯誤中恢復的任務量），可伸縮性（無狀態性使得服務器端可以 很容易的釋放資源，因為服務器端不必在多個request中保存狀態）。同時，這種規範的缺點也是顯而易見得，由於不能將狀態數據保存在服務器上的共享上 下文中，因此增加了在一系列request中發送重復數據的開銷,嚴重的降低了效率。
（3）緩存
為 了改善無狀態性帶來的網絡的低效性，我們填加了緩存約束。緩存約束允許隱式或顯式地標記一個response中的數據，這樣就賦予了客戶端緩存 response數據的功能，這樣就可以為以後的request共用緩存的數據，部分或全部的消除一部分交互，增加了網絡的效率。但是用於客戶端緩存了信 息，也就同時增加了客戶端與服務器數據不一致的可能，從而降低了可靠性。
B/S架構的優點是其部署非常方便，但在用戶體驗方面卻不是很理想。為了改善這種情況，我們引入了REST。
REST在原有的架構上增加了三個新規範：統一接口，分層系統和按需代碼。
（4）統一接口
REST 架構風格的核心特征就是強調組件之間有一個統一的接口，這表現在REST世界裏，網絡上所有的事物都被抽象為資源，而REST就是通過通用的鏈接器接口對 資源進行操作。這樣設計的好處是保證系統提供的服務都是解耦的，極大的簡化了系統，從而改善了系統的交互性和可重用性。並且REST針對Web的常見情況 做了優化，使得REST接口被設計為可以高效的轉移大粒度的超媒體數據，這也就導致了REST接口對其它的架構並不是最優的。
（5）分層系統
分層系統規則的加入提高了各種層次之間的獨立性，為整個系統的復雜性設置了邊界，通過封裝遺留的服務，使新的服務器免受遺留客戶端的影響，這也就提高了系統的可伸縮性。
（6）按需代碼
REST允許對客戶端功能進行擴展。比如，通過下載並執行applet或腳本形式的代碼，來擴展客戶端功能。但這在改善系統可擴展性的同時，也降低了可見性。所以它只是REST的一個可選的約束。
四： REST的設計準則
網絡上的所有事物都被抽象為資源（resource）；
每個資源對應一個唯一的資源標識符（resource identifier）；
通過通用的連接器接口（generic connector interface）對資源進行操作；
對資源的各種操作不會改變資源標識符；
所有的操作都是無狀態的（stateless）。
REST中的資源所指的不是數據，而是數據和表現形式的組合，比如“最新訪問的10位會員”和“最活躍的10為會員”在數據上可能有重疊或者完全相同，而 由於他們的表現形式不同，所以被歸為不同的資源，這也就是為什麽REST的全名是Representational State Transfer的原因。資源標識符就是URI(Uniform Resource Identifier)，不管是圖片，Word還是視頻文件，甚至只是一種虛擬的服務，也不管你是xml格式,txt文件格式還是其它文件格式，全部通過 URI對資源進行唯一的標識。
REST是基於Http協議的，任何對資源的操作行為都是通過Http協議來實現。以往的Web開發大多數用的都是Http協議中的GET和POST方 法，對其他方法很少使用，這實際上是因為對Http協議認識片面的理解造成的。Http不僅僅是一個簡單的運載數據的協議，而是一個具有豐富內涵的網絡軟 件的協議。他不僅僅能對互聯網資源進行唯一定位，而且還能告訴我們如何對該資源進行操作。Http把對一個資源的操作限制在4個方法以內：GET, POST,PUT和DELETE，這正是對資源CRUD操作的實現。由於資源和URI是一一對應的，執行這些操作的時候URI是沒有變化的，這和以往的 Web開發有很大的區別。正由於這一點，極大的簡化了Web開發，也使得URI可以被設計成更為直觀的反映資源的結構，這種URI的設計被稱作 RESTful的URI。這位開發人員引入了一種新的思維方式：通過URL來設計系統結構。當然了，這種設計方式對一些特定情況也是不適用的，也就是說不 是所有的URI都可以RESTful的。
REST 之所以可以提高系統的可伸縮性，就是因為它要求所有的操作都是無狀態的。由於沒有了上下文(Context)的約束，做分布式和集群的時候就更為簡單，也 可以讓系統更為有效的利用緩沖池(Pool）。並且由於服務器端不需要記錄客戶端的一系列訪問，也減少了服務器端的性能。
五：如何使用REST
對於開發人員來 說，關心的是如何使用REST架構，這裏我們來簡單談談這個問題。REST不僅僅是一種嶄新的架構，它帶來的更是一種全新的Web開發過程中的思維方式： 通過URL來設計系統結構。在REST中，所有的URL都對應著資源，只要URL的設計是良好的，那麽其呈現的系統結構也就是良好的。這點和TDD (Test Driven Development)很相似，他是通過測試用例來設計系統的接口，每一個測試用例都表示一系列用戶的需求。開發人員不需要一開始就編寫功能，而只需要 把需要實現的功能通過測試用例的形式表現出來即可。這個和REST中通過URL設計系統結構的方式類似，我們只需要根據需求設計出合理地URL，這些 URL不一定非要鏈接到指定的頁面或者完成一些行為，只要它們能夠直觀的表現出系統的用戶接口。根據這些URL，我們就可以方便的設計系統結構。從 REST架構的概念上來看，所有能夠被抽象成資源的東西都可以被指定為一個URL，而開發人員所需要做的工作就是如何能把用戶需求抽象為資源，以及如何抽 象的精確。因為對資源抽象的越為精確，對REST的應用來說就越好。這個和傳統MVC開發模式中基於Action的思想差別就非常大。設計良好的URL， 不但對於開發人員來說可以更明確的認識系統結構，對使用者來說也方便記憶和識別資源，因為URL足夠簡單和有意義。按照以往的設計模式，很多URL後面都 是一堆參數，對於使用者來說也是很不方便的。
六：REST和MVC的選擇
既然REST這 麽好用，那麽是不是所有的Web應用都能采取此種架構呢？答案是否定的。我們知道，直到現在為止，MVC(Model-View-Controller) 模式依然是Web開發最普遍的模式，絕大多數的公司和開發人員都采取此種架構來開發Web應用，並且其思維方式也停留於此。MVC模式由數據，視圖和控制 器構成，通過事件(Event)觸發Controller來改變Model和View。加上Webwork,Struts等開源框架的加入，MVC開發模 式已經相當成熟，其思想根本就是基於Action來驅動。從開發人員角度上來說，貿然接受一個新的架構會帶來風險，其中的不確定因素太多。並且REST新 的思維方式是把所有用戶需求抽象為資源，這在實際開發中是比較難做到的，因為並不是所有的用戶需求都能被抽象為資源，這樣也就是說不是整個系統的結構都能 通過REST的來表現。所以在開發中，我們需要根據以上2點來在REST和MVC中做出選擇。我們認為比較好的辦法是混用REST和MVC，因為這適合絕 大多數的Web應用開發，開發人員只需要對比較容易能夠抽象為資源的用戶需求采取REST的開發模式，而對其它需求采取MVC開發即可。這裏需要提到的就 是ROR(Ruby on Rails)框架，這是一個基於Ruby語言的越來越流行的Web開發框架，它極大的提高了Web開發的速度。更為重要的是，ROR(從1.2版本起)框 架是第一個引入REST做為核心思想的Web開發框架，它提供了對REST最好的支持，也是當今最成功的應用REST的Web開發框架。實際上，ROR的 REST實現就是REST和MVC混用，開發人員采用ROR框架，可以更快更好的構建Web應用。
一前言 ：
由於 REST 可以降低開發的復雜度，提高系統的可伸縮性，增強系統的可擴展性，簡化應用系統之間的集成，因而得到了廣大開發人員的喜愛，同時得到了業界廣泛的支持。比如 IBM，Google 等公司的很多產品都提供了 REST API 給開發人員；與此同時，大量的開源項目和雲計算服務都提供了 REST API 接口。
而在最近，一些新產品的開發甚至已經幾乎完全拋棄了傳統的類似 JSP 的技術， 轉而大量使用 REST 風格的構架設計， 即在服務器端所有商業邏輯都以 REST API 的方式暴露給客戶端， 所有瀏覽器用戶界面使用 widget，Ajax， HTML5 等技術，用 HTTP 的方式與後臺直接交互。
二：什麽是REST
REST是英文Representational State Transfer的縮寫，中文翻譯為“表述性狀態轉移”，他是由Roy
Thomas Fielding博士在他的論文 《Architectural Styles and the Design of Network-based Software Architectures》中提出的一個術語。REST本身只是為分布式超媒體系統設計的一種架構風格，而不是標準。
基於Web的架構，實際上就是各種規範的集合，這些規範共同組成了Web架構。比如Http協議，比如客戶端服務器模式，這些都是規範。每當我們在原有規 範的基礎上增加新的規範，就會形成新的架構。而REST正是這樣一種架構，他結合了一系列的規範，而形成了一種新的基於Web的架構風格。
三：REST規範
（1）客戶－服務器
這種規範的提出，改善了用戶接口跨多個平臺的可移植性，並且通過簡化服務器組件，改善了系統的可伸縮性。最為關鍵的是通過分離用戶接口和數據存儲這兩個關註點，使得不同用戶終端享受相同數據成為了可能。
（2）無狀態性
無狀態性是在客戶－服務器約束的基礎上添加的又一層規範。他要求通信必須在本質上是無狀態的，即從客戶到服務器的每個request都必須包含理解該 request所必須的所有信息。這個規範改善了系統的可見性（無狀態性使得客戶端和服務器端不必保存對方的詳細信息，服務器只需要處理當前 request，而不必了解所有的request歷史），可靠性（無狀態性減少了服務器從局部錯誤中恢復的任務量），可伸縮性（無狀態性使得服務器端可以 很容易的釋放資源，因為服務器端不必在多個request中保存狀態）。同時，這種規範的缺點也是顯而易見得，由於不能將狀態數據保存在服務器上的共享上 下文中，因此增加了在一系列request中發送重復數據的開銷,嚴重的降低了效率。
（3）緩存
為 了改善無狀態性帶來的網絡的低效性，我們填加了緩存約束。緩存約束允許隱式或顯式地標記一個response中的數據，這樣就賦予了客戶端緩存 response數據的功能，這樣就可以為以後的request共用緩存的數據，部分或全部的消除一部分交互，增加了網絡的效率。但是用於客戶端緩存了信 息，也就同時增加了客戶端與服務器數據不一致的可能，從而降低了可靠性。
B/S架構的優點是其部署非常方便，但在用戶體驗方面卻不是很理想。為了改善這種情況，我們引入了REST。
REST在原有的架構上增加了三個新規範：統一接口，分層系統和按需代碼。
（4）統一接口
REST 架構風格的核心特征就是強調組件之間有一個統一的接口，這表現在REST世界裏，網絡上所有的事物都被抽象為資源，而REST就是通過通用的鏈接器接口對 資源進行操作。這樣設計的好處是保證系統提供的服務都是解耦的，極大的簡化了系統，從而改善了系統的交互性和可重用性。並且REST針對Web的常見情況 做了優化，使得REST接口被設計為可以高效的轉移大粒度的超媒體數據，這也就導致了REST接口對其它的架構並不是最優的。
（5）分層系統
分層系統規則的加入提高了各種層次之間的獨立性，為整個系統的復雜性設置了邊界，通過封裝遺留的服務，使新的服務器免受遺留客戶端的影響，這也就提高了系統的可伸縮性。
（6）按需代碼
REST允許對客戶端功能進行擴展。比如，通過下載並執行applet或腳本形式的代碼，來擴展客戶端功能。但這在改善系統可擴展性的同時，也降低了可見性。所以它只是REST的一個可選的約束。
四： REST的設計準則
網絡上的所有事物都被抽象為資源（resource）；
每個資源對應一個唯一的資源標識符（resource identifier）；
通過通用的連接器接口（generic connector interface）對資源進行操作；
對資源的各種操作不會改變資源標識符；
所有的操作都是無狀態的（stateless）。
REST中的資源所指的不是數據，而是數據和表現形式的組合，比如“最新訪問的10位會員”和“最活躍的10為會員”在數據上可能有重疊或者完全相同，而 由於他們的表現形式不同，所以被歸為不同的資源，這也就是為什麽REST的全名是Representational State Transfer的原因。資源標識符就是URI(Uniform Resource Identifier)，不管是圖片，Word還是視頻文件，甚至只是一種虛擬的服務，也不管你是xml格式,txt文件格式還是其它文件格式，全部通過 URI對資源進行唯一的標識。
REST是基於Http協議的，任何對資源的操作行為都是通過Http協議來實現。以往的Web開發大多數用的都是Http協議中的GET和POST方 法，對其他方法很少使用，這實際上是因為對Http協議認識片面的理解造成的。Http不僅僅是一個簡單的運載數據的協議，而是一個具有豐富內涵的網絡軟 件的協議。他不僅僅能對互聯網資源進行唯一定位，而且還能告訴我們如何對該資源進行操作。Http把對一個資源的操作限制在4個方法以內：GET, POST,PUT和DELETE，這正是對資源CRUD操作的實現。由於資源和URI是一一對應的，執行這些操作的時候URI是沒有變化的，這和以往的 Web開發有很大的區別。正由於這一點，極大的簡化了Web開發，也使得URI可以被設計成更為直觀的反映資源的結構，這種URI的設計被稱作 RESTful的URI。這位開發人員引入了一種新的思維方式：通過URL來設計系統結構。當然了，這種設計方式對一些特定情況也是不適用的，也就是說不 是所有的URI都可以RESTful的。
REST 之所以可以提高系統的可伸縮性，就是因為它要求所有的操作都是無狀態的。由於沒有了上下文(Context)的約束，做分布式和集群的時候就更為簡單，也 可以讓系統更為有效的利用緩沖池(Pool）。並且由於服務器端不需要記錄客戶端的一系列訪問，也減少了服務器端的性能。
五：如何使用REST
對於開發人員來 說，關心的是如何使用REST架構，這裏我們來簡單談談這個問題。REST不僅僅是一種嶄新的架構，它帶來的更是一種全新的Web開發過程中的思維方式： 通過URL來設計系統結構。在REST中，所有的URL都對應著資源，只要URL的設計是良好的，那麽其呈現的系統結構也就是良好的。這點和TDD (Test Driven Development)很相似，他是通過測試用例來設計系統的接口，每一個測試用例都表示一系列用戶的需求。開發人員不需要一開始就編寫功能，而只需要 把需要實現的功能通過測試用例的形式表現出來即可。這個和REST中通過URL設計系統結構的方式類似，我們只需要根據需求設計出合理地URL，這些 URL不一定非要鏈接到指定的頁面或者完成一些行為，只要它們能夠直觀的表現出系統的用戶接口。根據這些URL，我們就可以方便的設計系統結構。從 REST架構的概念上來看，所有能夠被抽象成資源的東西都可以被指定為一個URL，而開發人員所需要做的工作就是如何能把用戶需求抽象為資源，以及如何抽 象的精確。因為對資源抽象的越為精確，對REST的應用來說就越好。這個和傳統MVC開發模式中基於Action的思想差別就非常大。設計良好的URL， 不但對於開發人員來說可以更明確的認識系統結構，對使用者來說也方便記憶和識別資源，因為URL足夠簡單和有意義。按照以往的設計模式，很多URL後面都 是一堆參數，對於使用者來說也是很不方便的。
六：REST和MVC的選擇
既然REST這 麽好用，那麽是不是所有的Web應用都能采取此種架構呢？答案是否定的。我們知道，直到現在為止，MVC(Model-View-Controller) 模式依然是Web開發最普遍的模式，絕大多數的公司和開發人員都采取此種架構來開發Web應用，並且其思維方式也停留於此。MVC模式由數據，視圖和控制 器構成，通過事件(Event)觸發Controller來改變Model和View。加上Webwork,Struts等開源框架的加入，MVC開發模 式已經相當成熟，其思想根本就是基於Action來驅動。從開發人員角度上來說，貿然接受一個新的架構會帶來風險，其中的不確定因素太多。並且REST新 的思維方式是把所有用戶需求抽象為資源，這在實際開發中是比較難做到的，因為並不是所有的用戶需求都能被抽象為資源，這樣也就是說不是整個系統的結構都能 通過REST的來表現。所以在開發中，我們需要根據以上2點來在REST和MVC中做出選擇。我們認為比較好的辦法是混用REST和MVC，因為這適合絕 大多數的Web應用開發，開發人員只需要對比較容易能夠抽象為資源的用戶需求采取REST的開發模式，而對其它需求采取MVC開發即可。這裏需要提到的就 是ROR(Ruby on Rails)框架，這是一個基於Ruby語言的越來越流行的Web開發框架，它極大的提高了Web開發的速度。更為重要的是，ROR(從1.2版本起)框 架是第一個引入REST做為核心思想的Web開發框架，它提供了對REST最好的支持，也是當今最成功的應用REST的Web開發框架。實際上，ROR的 REST實現就是REST和MVC混用，開發人員采用ROR框架，可以更快更好的構建Web應用。
論REST架構與傳統MVC