[转]REST
表象化狀態轉變(英文:Representational State Transfer,簡稱REST)是Roy Fielding博士在2000年他的博士論文中提出來的一種軟件架構風格。
????? 目前在三種主流的Web服務實現方案中,因為REST模式的Web服務與復雜的SOAP和XML-RPC對比來講明顯的更加簡潔,越來越多的web服務開始采用REST風格設計和實現。例如,Amazon.com提供接近REST風格的Web服務進行圖書查找;雅虎提供的Web服務也是REST風格的。
宗旨
????? REST 從資源的角度來觀察整個網絡,分布在各處的資源由URI確定,而客戶端的應用通過URI來獲取資源的表形。獲得這些表形致使這些應用程序轉變了其狀態。隨著不斷獲取資源的表形,客戶端應用不斷地在轉變著其狀態,所謂表形化的狀態轉變(Representational State Transfer)。
這一觀點不是憑空臆造的,而是通過觀察當前Web互聯網的運作方式而抽象出來的。Roy Fielding 認為,
“ 設計良好的網絡應用表現為一系列的網頁,這些網頁可以看作的虛擬的狀態機,用戶選擇這些鏈接導致下一網頁傳輸到用戶端展現給使用的人,而這正代表了狀態的轉變。 ”
REST的要求
1.客戶端和服務器結構
2.連接協議具有無狀態性
3.能夠利用Cache機制增進性能
4.層次化的系統
5.Code On Demand - Javascript
關于狀態
??? 應該注意區別應用的狀態和連接協議的狀態。REST對于連接的無狀態性實際上要求每次經過無狀態的連接協議傳送的信息必須包含應用中所有的狀態信息。
實現舉例
例如,一個簡單的網絡商店應用,
列舉所有商品,
GET http://www.store.com/products
具體某一件商品,
GET http://www.store.com/product/12345
下單購買,
POST http://www.store.com/order,
<purchase-order>
? <item> ... </item>
</purchase-order>
REST的優點
可以利用緩存Cache來提高響應速度
通訊本身的無狀態性可以讓不同的服務器的處理一系列請求中的不同請求,提高服務器的擴展性
瀏覽器即可作為客戶端,簡化軟件需求
相對與其他疊加在HTTP協議之上的機制,REST的軟件依賴性更小
不需要額外的資源發現機制
在軟件技術演進中的長期的兼容性更好
REST使用http方法(GET, PUT, DELETE, POST)來調用API或管理資源.
從RPC API的角度來看,這些方法的使用目標如下:
Http方法???? 使用目標
GET????????? 可以緩沖的 resources
GET, PUT???? 可以緩沖和修改的 resources
GET, PUT, DELETE 可以緩沖,修改和刪除的 resources
POST???????? 不能緩沖的 resources
REST的設計準則
REST架構是針對Web應用而設計的,其目的是為了降低開發的復雜性,提高系統的可伸縮性。REST提出了如下設計準則:
1.網絡上的所有事物都被抽象為資源(resource);
2.每個資源對應一個唯一的資源標識符(resource identifier);
3.通過通用的連接器接口(generic connector interface)對資源進行操作;
4.對資源的各種操作不會改變資源標識符;
5.所有的操作都是無狀態的(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這么好用,那么是不是所有的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不僅僅在Web開發上貢獻了自己的力量,同時也讓我們學到了如何把軟件工程原則系統地應用于對一個真實軟件的設計和評估上。
?
本文是對網絡上的文章進行了一下整理,文字來源:
http://zh.wikipedia.org/wiki/REST
http://blog.csdn.net/wangjj_016/archive/2008/12/26/3615948.aspx
http://www.cnblogs.com/riceball/archive/2008/06/22/1227553.html
轉載于:https://www.cnblogs.com/xray2005/archive/2009/08/27/1554995.html
總結
- 上一篇: ASP.NET MVC 上传文件
- 下一篇: 兔子不吃窝边草,跳槽不跳窝边槽。。。