白話REST-識別真假REST

轉自：http://blog.csdn.net/ugg/article/details/9026649
php

你們對REST的認識？html

談到REST你們的第一印象就是經過http協議的GET,POST,DELETE,PUT方法實現對url資源的CRUD（建立、讀取、更新和刪除）操做。好比
http://www.aizher.com/c2/（讀取）
仍然保持爲 [GET] http://www.aizher.com/c2/
http://www.aizher.com/c2/create（建立）
改成 [POST] http://www.aizher.com/c2/
http://www.aizher.com/c2/update（更新）
改成 [PUT] http://www.aizher.com/c2/
http://www.aizher.com/c2/delete（刪除）
改成 [DELETE] http://www.aizher.com/c2/
這種形式的REST只是CRUD（增刪改查），從這個層面上，好像REST只是和RPC一個層面的東西，沒有什麼了不得，其實這些都是對REST誤讀。也誤導你們實現REST時，特種注重GET,POST,PUT,DELETE方法的處理，包括一些所謂的REST框架，好比JBoss RESTEasy，Restlet Tomcat。究其緣由是， REST提供了一組架構約束，看成爲一個總體來應用時，強調組件交互的可伸縮性、接口的通用性、組件的獨立部署、以及用來減小交互延遲、加強安全性、封裝遺留系統的中間組件。其實從整個REST推導過程當中能夠了解到，REST沒有說起HTTP協議的任何方法，只是後期你們從REST的統一接口中擴展出這些操做概念。前端

到底什麼是REST？
         REST是中文翻譯爲表徵狀態轉移（英文：Representational State Transfer）是Roy Fielding博士在2000年他的博士論文中提出來的一種軟件架構風格。從字面意思來講，「表述」是很難理解是什麼東西的？從論文上咱們能夠看到表述，通常指HTML文檔（包括json，xml等），jpeg等圖片資源。
         先從理論層次上咱們看一下REST是怎麼推導來的（參考論文第五章）
         Web架構背後的設計基本原理，可以被描述爲由一組應用於架構中元素之上的約束組成的架構風格。當將每一個約束添加到進化中的風格時，會產生一些影響。經過檢查這些影響，咱們就可以識別出Web的約束所致使的屬性。而後就可以應用額外的約束來造成一種新的架構風格，這種風格可以更好地反映出現代Web架構所期待的屬性。經過簡述REST做爲架構風格的推導過程，後面各節將會詳細描述組成REST風格的各類特定約束
        1：從「空」風格開始。從架構的觀點來看，空風格描述了一個組件之間沒有明顯邊界的系統，這就是咱們描述REST的起點。
        2：客戶-服務器。客戶-服務器約束背後的原則是分離關注點。經過分離用戶接口和數據存儲這兩個關注點，咱們改善了用戶接口跨多個平臺的可移植性；同時經過簡化服務器組件，改善了系統的可伸縮性。
        3：無狀態。這個約束致使了可見性、可靠性和可伸縮性三個架構屬性，可是無狀態並非沒有缺點的，無狀態增長了在一系列請求中發送的重複數據（每次交互的開銷），可能會下降網絡性，正由於這個缺點，因此在REST風格中增長了緩存的考慮。
        4：緩存，添加緩存約束的好處在於，它們有可能部分或所有消除一些交互，從而經過減小一系列交互的平均延遲時間，來提升效率、可伸縮性和用戶可覺察的性能。可是緩存仍是有缺點的，若是緩存中陳舊的數據與將請求直接發送到服務器獲得的數據差異很大，那麼緩存會下降可靠性。注意這裏的緩存並非指MC，redis之類的緩存，而是在網絡代理中，好比proxy服務器上的緩存機制。
         5：統一接口。使REST架構風格區別於其餘基於網絡的架構風格的核心特徵是，它強調組件之間要有一個統一的接口，爲了得到統一的接口，須要有多個架構約束來指導組件的行爲。REST由四個接口約束來定義：資源的識別（identification ofresources）、經過表述對資源執行的操做、自描述的消息（self-descriptive messages）、以及做爲應用狀態引擎的超媒體相關因素REST和其餘概念關係。統一接口的雖然晦澀，可是它是REST風格核心特徵，也是前面咱們討論經過CURD方式操做資源的一種表現，也是咱們最容易接觸感覺到的一層，後面淘寶，微博，微信開放平臺的開放接口，其實就是咱們接觸這個平臺的統一接口，評價一個開發平臺是否REST的標準，也在於這個平臺的設計者對統一接口的理解。
         6：，分層系統，分紅系統風格經過限制組件的行爲（即，每一個組件只能「看到」與其交互的緊鄰層），將架構分解爲若干等級的層。經過將組件對系統的知識限制在單一層內，爲整個系統的複雜性設置了邊界，而且提升了底層獨立性。分層系統增長了數據處理的開銷和延遲，所以下降了用戶可覺察的性能對於一個支持緩存約束的基於網絡的系統來講，能夠經過在中間層使用共享緩存所得到的好處來彌補這一缺點。正由於REST風格有這樣的缺點，纔會特地強調緩存的做用。
         7：按需代碼，經過下載並執行applet形式或腳本形式的代碼，REST容許對客戶端的功能進行擴展，看似簡單的一種風格設計，其實對B/S貢獻最大的就是這個特性，如今ajax的底層其實就是按需代碼機制。
        小結：基於網絡的架構風格圖形化地描述了REST約束的來源java

數據流風格（Data-flow Styles）程序員

   PF：管道和過濾器（Pipe and Filter，PF）
   UPF：統一管道和過濾器（Uniform Pipe andFilter，UPF）
複製風格（Replication Styles）
   RR：複製倉庫（ReplicatedRepository，RR）--apache 多woker-利用多個進程提供相同的服務，來改善數據的可訪問性（accessibility of data）和服務的可伸縮性（scalability of service）。CVS[www.cyclic.com]這樣的遠程版本控制系統
   $ 緩存（Cache，$）
分層風格（Hierarchical Styles）
客戶-服務器（Client-Server，CS）(rpc,corba)
分層系統（Layered System，LS）和分層-客戶-服務器（Layered-Client-Server，LCS）
客戶-無狀態-服務器（Client-Stateless-Server，CSS）
客戶-緩存-無狀態-服務器（Client-Cache-Stateless-Server，C$SS）
分層-客戶-緩存-無狀態-服務器（Layered-Client-Cache-Stateless-Server，LC$SS）
遠程會話（Remote Session，RS）(FTP)
遠程數據訪問（Remote Data Access，RDA）(sql)
移動代碼風格（Mobile Code Styles）
虛擬機（Virtual Machine，VM）
遠程求值（Remote Evaluation，REV）
按需代碼（Code on Demand，COD）
分層-按需代碼-客戶-緩存-無狀態-服務器（Layered-Code-on-Demand-Client-Cache-Stateless-Server，LCODC$SS）
移動代理（Mobile Agent，MA
點對點風格（Peer-to-Peer Styles）
基於事件的集成（Event-based Integration，EBI）
C2
分佈式對象（Distributed Objects，DO）
被代理的分佈式對象（Brokered Distributed Objects，BDO）
以上就是REST推導過程，簡單的說，REST要求
        1:客戶端和服務器結構
        2:鏈接協議具備無狀態性
        3:可以利用Cache機制增進性能
        4:層次化的系統
        5:統一接口規範分層交互
        6:隨需代碼 - Javascript （可選）
根據以上的描述，咱們其實發現HTTP是一種典型的REST風格，這也難怪，在1994年提出REST風格時，REST被稱做「HTTP對象模型」，可是那個名稱經常引發誤解，令人們誤覺得它是一個HTTP服務器的實現模型。這個名稱「表述性狀態轉移」是有意喚起人們對於一個良好設計的Web應用如何運轉的印象。反過來看HTTP就是REST的具體實現。在一個REST風格中，咱們可以感覺到的就是統一接口的數據，這些數據包括因此，當咱們開發一個web服務時，好比一個網站，因爲使用了HTTP(HTTPS)協議，其實就是一種REST風格，可是在這個REST風格中咱們着重處理的是兩點
       1：URI，即所謂的資源，網站的uri設計
       2：統一接口，即所謂的PUT,GET,POST,DELETE方法
雖然咱們的網站是REST的風格的，可是因爲統一接口設計的很差，致使咱們網站在訪問請求時，效率低下，以及可擴展性差。在深刻淺出REST中，做者總結了五條關鍵原
        1：爲全部「事物」定義ID
        2：將全部事物連接在一塊兒
        3：使用標準方法
        4：資源多重表述
        5：無狀態通訊
其中前四條就是對統一接口中的數據元素，第一二條講的就是uri，第三四條講的是控制數據。第五條無狀態通訊，這個須要特別說明下，無狀態通訊是指服務器和客戶端通訊是無狀態的，假如咱們的系統中使用Session保存客戶端狀態，這種狀況就是非無狀態通訊，是一種unREST的方式。可是應用自己是有狀態的，好比用戶登陸先後，就是應用狀態的變化。
       以上的描述，偏向理論東西最多，也不容易理解，咱們經過對比幾組協議更好的理解REST
REST和HTTP的關係
       HTTP（HyperTextTransfer Protocol）超文本轉移協議，中國的權威老是翻譯成超文本傳輸協議，這是一種錯誤的翻譯，HTTP一層應用協議，和傳輸沒有一點關係。中國的磚家，自做多情翻譯成傳輸，從這一刻起，開始修正吧，HTTP即爲超文本轉移協議。
       HTTP中第二個T和REST中的T都是一個含義：Transfer，轉移的意思。前者是指超文本轉移的，後者是說表述轉移的，二者相同是有緣由的。前者是隻具體數據的轉移，後者是表述狀態概念上轉移。二者是一個抽象，一個實現的關係，相似於URI和URL的關係，這塊在Roy Fielding的論文中也有體現，在1994年提出REST風格時，REST被稱做「HTTP對象模型」，可是那個名稱經常引發誤解，令人們誤覺得它是一個HTTP服務器的實現模型。這個名稱「表述性狀態轉移」是有意喚起人們對於一個良好設計的Web應用如何運轉的印象。因此，通俗的講，HTTP就是在REST風格的一種具體實現。
         雖然，HTTP協議是REST的一個實現，可是並不意味着HTTP的全部特性都符合REST。
        1：HTTP沒法區分權威的響應，沒法區分請求來自目前服務器，仍是中間代理。
        2：COOKIE，使用cookie記錄用戶信息，明顯違背了REST中的無狀態特性，使數據傳輸不透明，同理對於Session也是違反REST。
        3：必須擴展。在現代Web架構中一個還沒有匹配REST架構風格的自描述消息約束的方面，主要是由於在現有HTTP語法中實現一個支持必需擴展的框架的成本，超過了咱們可能從必需擴展中得到的任何明顯的好處
        4：混合元數據。HTTP被設計用來跨越一個網絡鏈接擴展通用的鏈接器接口。所以，它有意匹配這個接口的特性，包括將參數描述爲控制數據、元數據、以及表述。然而，HTTP/1.x協議家族的兩個最嚴重的侷限是：它沒有從語義上區分表述的元數據和消息的控制信息（都是做爲頭信息字段來傳輸）；並且不容許爲了對消息進行完整性檢查，而對元數據進行有效地分層。
        5：MIME語法，好比.html後綴，其實這並非HTTP協議所必須的。MIME語法的問題在於它假設傳輸機制是有損耗的，會故意將換行和內容長度等信息破壞掉。所以其語法有不少的冗餘，而且對於任何並不是基於有損耗傳輸機制的系統來講都是低效的，這使得它對於HTTP是不適合的。既然HTTP/1.1有能力支持不兼容協議的部署，保留MIME的語法對於HTTP的下一個主要的版本而言並非必需的，儘管如此，仍是有可能爲表述的元數據繼續使用不少標準化的協議元素。
        6：將響應匹配到請求，當須要描述哪個響應屬於哪個請求的時候，HTTP消息並非自描述的。早期的HTTP基於每一個鏈接單個請求和響應，所以沒有覺察到須要有將響應與相關的請求綁定在一塊兒的消息控制數據。所以，請求的順序決定了響應的順序，這意味着HTTP依賴於傳輸機制的鏈接（transport connection）來決定這個匹配。
       總結起來講，對於web開發者來講，最長接觸的就是cookie和mime語法，因此在架構良好的系統同，儘可能避免使用cookie，mime語法，也是一種REST方式。固然對於cookie要區分對待，並非使用cookie，就意外着違反REST風格，主要看cookie的應用場景，若是cookie用來記錄客戶端信息，而並不維護客戶端狀態，其實cookie仍是可使用。可是Session就是徹底反REST的，它違反了REST中的無狀態性，咱們如今不少應用仍是喜歡使用Session記錄用戶登陸狀態，其實這是一種unREST的方式。對於MIME，就HTTP協議來講MIME並非必須的，若是有條件了能夠不使用。
       固然，在HTTP協議制定過程當中，HTTP的不少特性也是在REST風格指導下定義的，好比，好比緩存控制cache-control，Etag；協議版本控制，HTTP-version。還有如今虛擬主機，就是由於Host字段，這也是REST風格對HTTP協議的做用。
REST和URI的關係
       HTTP是REST的一種實現，其實URI也是REST的一種實現，統一資源標識符（URI）既是Web架構的最簡單的元素，也是最重要的元素。Web地址的規範也定義了咱們所稱之爲的「資源」的概念的範圍和語義，這個概念自從早期的Web架構以來發生了變化。REST被用來爲URI標準定義術語「資源」，也被用來定義經過它們的表述來操做資源的通用接口的所有語義。
       儘管URI的設計與REST的標識符的架構概念相匹配，單單依靠語法卻不足以迫使命名權威按照資源模型來定義他們本身的URI。一種形式的濫用是在由一個超媒體響應形式的表述（a hypermedia response representation）所引用的全部的URI中包括標識當前用戶的信息。這樣內嵌的用戶id可以被用來維護服務器端會話的狀態，經過記錄用戶的動做來跟蹤他們的行爲，或者跨多個動做攜帶用戶的首選項（例如Hyper-G網關[84]）。儘管如此，因爲違反了REST的約束，這些系統會致使共享緩存變得效率低下，這下降了服務器的可伸縮性，而且在一個用戶與其餘用戶共享那些引用時會致使不但願的結果。另外一個與REST的資源接口的衝突發生在當軟件試圖將Web看做一個分佈式文件系統的時候。這是URI和REST相反的兩個方面，一開始你們看到第一條緣由時不是很瞭解，舉個例子來講，好比咱們有三個頁面。
http://www.aizher.com/?uid=123
http://www.aizher.com/c2/?uid=123
http://www.aizher.com/item/123456.html?uid=123
       經過在url中傳入uid記錄跟蹤用戶的行爲，以及維護和服務器端的回話狀態，這是一種顯著unREST的方式。再好比，在淘寶的web服務中，爲了統計數據，在每一個url上加上spm，
http://www.tmall.com/yao?spm=1.1000386.221827.31.y2H5kz
        這種方式，是否違法REST？你們能夠考慮下（答案是不違反的，具體緣由能夠本身考慮）。
        至於第二條，其實更多的CDN（內容分發系統），CDN分發的是文件，因此能夠很容易的作鏡像，而對於web內容是作不到這樣的，因此，CDN方式是URI一種特殊存在形式，不能推廣到所有web內容。
REST和SOAP對比
        SOAP簡單對象訪問協議（SOAP，全寫爲Simple Object Access Protocol）是交換數據的一種協議規範，使用在計算機網絡Web服務（web service）中，交換帶結構信息。從這裏能夠看到SOAP是一種數據交換協議，而REST是一種架構風格，二者實際上是沒有可比性的。可是爲何老是把二者放在一塊對比那？
        REST和SOAP以及XML-RPC實現方式不一樣，可是目的是同樣的，即提供web服務，做爲一種總體來講，因此你們喜歡把這三者進行對比。可是其本質上來講，這三者不是一類東西，做爲一篇介紹REST的文章，若是不說起SOAP的具體調用方式，你們是不會意識到REST的簡單。
         SOAP是一種交換數據的協議規範，他自己不具有傳輸性，可是他可使用http協議，socket做爲載體進行傳輸。一個典型的SOAP結構爲

web

SOAP 消息必須用 XML 來編碼
SOAP 消息必須使用 SOAP Envelope 命名空間
SOAP 消息必須使用 SOAP Encoding 命名空間
SOAP 消息不能包含 DTD 引用
SOAP 消息不能包含 XML 處理指令

         提到SOAP不得不提的是另外兩個概念，WSDL,UDDI。WSDL（Web服務描述語言，Web Services Description Language）是爲描述Web服務發佈的XML格式。SOAP就是使用WSDL來描述web服務的。UDDI是統一描述、發現和集成（Universal Description, Discovery,and Integration）的縮寫。它是一個基於XML的跨平臺的描述規範，可使世界範圍內的企業在互聯網上發佈本身所提供的服務。SOAP，WSDL，UDDI這三者是W3C中定義Web service的三個核心組件。
        SOAP：一個基於XML的可擴展消息信封格式，需同時綁定一個傳輸用協議。這個協議一般是HTTP或HTTPS，但也多是SMTP或XMPP。
        WSDL：一個XML格式文檔，用以描述服務端口訪問方式和使用協議的細節。一般用來輔助生成服務器和客戶端代碼及配置信息。
        UDDI：一個用來發布和搜索WEB服務的協議，應用程序可藉由此協議在設計或運行時找到目標WEB服務。
三者能夠相互獨立，也能夠相互融合使用，理想的應用場景是
        Web服務提供者：經過SOAP描述交互數據，使用WSDL描述服務器端口訪問方式，在UDDI註冊本身的Web服務，以方便調用者查找。
        Web服務的消費者：在UDDI上查找web 服務，調用WSDL得到服務接口的訪問方式和接口細節，使用SOAP交互數據。以PHP爲例（須要soap擴展），調用一個SOAPajax

[php] view plain copy

function soapCall($url, $functionName,$params) {
$c =new SoapClient($url, array('encoding'=>'GBK'));
$types = $c->__getTypes();
$paramArray = array();
for($i = 0; $i < count($params); ++$i) {
$p[$paramArray[$i]] = $params[$i];
}
$r =$c->$functionName($p);
foreach ($r as $key => $val) {
return $val;
}
}
$serviceUrl="http://xx.xxx.xxx.xxx:8047/MessageSenderWebService?wsdl";
$result =soapCall($serviceUrl,$serviceMethod,$ary);

綜合上面所述，SOAP的缺點是

定義嚴格。必須符合SOAP的格式，參考規範要求。
須要有專門客戶端解析soap協議，php須要soap擴展。
消息體大，大量信息用於描述Envelope，header。
服務器端，在web server的基礎上，還須要單獨部署服務，好比在jetty，tomcat須要部署AXIS。
服務器端代碼可複用性差，這是相對於web來講。
須要到註冊中心UDDI發佈，雖然是非必須條件，可是也同樣會麻煩。
         SOAP方式的優勢也很明顯，格式規範標準，並在最重要的是有ws-*標準協議擴展保證數據交換的安全，規範。這點REST方式沒有配套的協議，爲了確保安全，基本上採用sign簽名的方式，後面會詳細講解。
        小結：REST和SOAP本無對比性，放在一塊的目的主要是說明SOAP如何使用，方便對比下面的REST方案。
REST和XML-RPC對比
         XML-RPC是一個遠程過程調用（遠端程序呼叫）（remote procedure call，RPC)的分佈式計算協議，經過XML將調用函數封裝，並使用HTTP協議做爲傳送機制。後來在新的功能不斷被引入下，這個標準慢慢演變成爲今日的SOAP協定。如今直接使用XML-RPC的方式已經不多了。redis

REST與SOA對比
SOA面向服務的體系結構（Service-oriented architecture）是構造分佈式計算的應用程序的方法。它將應用程序功能做爲服務發送給最終用戶或者其餘服務。
SOA採用開放標準、與軟件資源進行交互並採用表示的標準方式，SOA是一個組件模型，它將應用程序的不一樣功能單元（稱爲服務）經過這些服務之間定義良好的接口和契約聯繫起來。接口是採用中立的方式進行定義的，它應該獨立於實現服務的硬件平臺、操做系統和編程語言。這使得構建在各類這樣的系統中的服務能夠以一種統一和通用的方式進行交互。sql

參考SOA面向服務器的體系架構的定義，和REST的面向資源的體系架構（ROA）對比，發現二者有很多相同點，好比
        一、統一的服務契約接口與服務接口。
        二、鬆散的耦合。
        三、只要有權限均可以進行訪問
REST與SOA的不一樣點
       一、REST風格下的，只有一種協議，那就是HTTP。而SOA有多種協議，好比：TCP、HTTP等多種協議
       二、使用方式上的不一樣。REST只要客戶端可以模擬HTTP請求，經過標準的HTTP動做，均可以進行訪問。
       三、REST寄宿時，雖然能夠選擇多種寄宿方式，但必須有應用服務器的支持。
        REST限定了http協議上的服務接口，鬆散耦合，而SOA沒有這方面的限定，這一點的差別，在具體實現就千差萬別。不管是REST風格，仍是ROA，或者SOAP，以及RMI等，其實都屬於SOA的範疇。
        總結：REST和SOA的本質區別仍是資源與服務的區別，資源經過兩部分定義：資源URL和資源所提供的全部操做上定義的輸入/輸出參數。服務並非某個編程結構或一組APIs，而是一個用於實現企業解決方案的架構（設計單元、實現以及維護）和部署構件，而且可由多種方式實現，資源和服務自己屬於包含被包含的關係，因此REST與SOA也是包含於被包含的意思。
REST與RPC對比？
        REST和RPC自己也沒有直接關係，REST是架構風格，而RPC是一個協議。遠程過程調用（Remote Procedure Call，RPC）是一個計算機通訊協議。該協議容許運行於一臺計算機的程序調用另外一臺計算機的子程序，而程序員無需額外地爲這個交互做用編程。若是涉及的軟件採用面向對象編程，那麼遠程過程調用亦可稱做遠程調用或遠程方法調用，例：Java RMI，CORBA, DCOM等等。
淘寶的HSF服務，其實就是一種RMI方法。
小結：
         經過REST與SOAP，SOA，XML-RPC，RPC，HTTP，URI的對比，咱們繪製以下關係圖
apache

         REST風格是旨在解決服務器通訊的一種架構風格。REST，RPC，SOAP三者同爲SOA的一種實現手段。其REST，RPC，SOAP自身又有不少與之關聯的概念和技術，協議。但願經過以上對比，先開REST的神祕面紗。
         REST提出概念後，其實並無像SOAP和RPC協議那樣的火爆起來，其中一方面的緣由是REST並不像是SOAP和RPC協議那樣，有個具體看的見的東西，他只是一種架構風格，屬於高級抽象，在應用普及方面先天不足，外加上沒有一個合適的爆發點。另外，在REST以前已經有了SOAP和RPC，因此在考慮到遠程服務通訊時，你們首先想到的仍是這二者。REST熱，是因爲AJAX的火爆引發的。話說，2005年2月8日-google maps發佈，讓你們驚豔的是WEB能夠作的這麼帥，AJAX的概念隨之火爆，而支持AJAX火爆的一個點就是REST，不管是SOAP仍是XML-RPC都沒法很好的支持AJAX的請求，試想一下，ajax先調用wsdl，再調用服務接口，這個過程會讓任何程序崩潰掉，在這裏WSDL是沒有任何用處，AJAX須要一種支持web服務，可是又不須要WSDL的方法，這時候天然而然的想到的REST，雖然AJAX中的X是XML的縮小，XML因爲先天不足，在web服務中，逐漸被json取代。
         除了AJAX火爆外，SaaS(Software as a Service) 概念火爆，SasS，iaas，paas合在一塊即雲計算，雲計算的興起，尤爲是內部雲，更須要一種簡單，方面的web服務通訊方式。而REST正好知足這方面的需求，部署簡單，調用方便，客戶端使用curl就能夠。
         於此同時，2006年3月開始，亞馬遜S3上線，真正的Restful API。2007年5月24日，facebook推出開放平臺，SOAP，REST並存方式。2008年，淘寶開放平臺，REST方式。人人，QQ，微博開放平臺，REST方式。至此到之後作開放平臺必須使用REST方式，而SOAP，XML-RPC方式在互聯網行業幾乎被遺忘，在討論WEB服務時，動輒REST方式。
         REST的標籤：雲計算，開發平臺，AJAX
REST之因此在雲計算，開放平臺，AJAX方面遍地開花，是因爲REST的這些優勢，正好符合雲計算，開放平臺，AJAX的應用場景。
1）輕量級的解決方案，沒必要向SOAP那樣要構建一個標準的SOAP XML。
2）可讀性比較好:能夠把URL的名字取得有實際意義。
3）不須要SDK支持：直接一個Http請求就能夠，可是SOAP則可能須要使用到一些Web service的類庫（例如Apache的Axis）

REST框架有哪些？
         REST是一種架構風格，而不是一種具體實現。而目前主流的WEB server又不能很好的支持REST，包括Apache。因此有機構，我的開發了很多REST框架，這些REST框架，說到底解決的就是HTTP的請求方法，對GET,POST,UPDATE,DELETE的處理，其餘並沒有新意，這些框架在實際應用中，效果並非很好，其中一條緣由是，REST框架又使REST風格變得複雜，通常狀況下，不推薦使用。
         常見的REST框架有
         Ruby on Rails1.2之後的版本支持REST model。
        JBoss RESTEasy， JBoss的REST實現
        Restlet Tomcat的REST實現
        ZendFramework經過Zend_Rest組件來實現Rest功能，框架CakePHP，相似Rails風格。
        Apache Wink，java框架
        Project Jersey 是 Sun® 公司提供的、用於構建 RESTful Web 服務的。
微博，淘寶，微信開發平臺，誰最REST
         1：微博API
                   訪問連接：http://open.weibo.com/wiki/%E5%BE%AE%E5%8D%9AAPI
         微博的接口分爲，微博接口，評論接口，帳號接口，好友分組接口等等分類，每種分類對應一組API接口，好比讀取接口
         https://api.weibo.com/2/statuses/public_timeline.json（微博組）
         https://api.weibo.com/2/comments/show.json（評論組）
         https://api.weibo.com/2/users/show.json（用戶組）
         其中URL中的2是版本，statuses,comments,users是每類的分組。微博的API，是通過贊成歸還的，每種url表明一種資源，是一種REST方式，只不過2做爲版原本使用有點2

2：淘寶的API
         訪問連接：http://open.taobao.com/doc/index.htm?spm=0.0.0.0.uD2CE3
         淘寶API有
         用戶API，提供了用戶基本信息查詢功能
        類目API，提供了標準類目，類目屬性和類目屬性值的查詢功能
        商品API，提供了商品以及商品相關的sku，郵費增長，修改功能
        交易API，提供了訂單下載，修改收貨地址、修改交易備註等功能
        評價API，提供了評價的添加和查詢功能
        物流API，提供了發貨，物流單詳情，區域地址和物流公司信息查詢功能
        店鋪API，提供了店鋪查詢，店鋪自定義類目的查詢和更新。
        分銷API，提供了分銷商信息和採購單信息的查詢以及分銷產品的添加和更新等功能
        旺旺API，提供了旺旺聊天記錄，平均等待時間，客服評價統計，客服未回覆人數和客服接待數等績效考覈功能
        淘客API，提供了淘寶客商品列表和淘寶客單品詳情推廣，店鋪推廣，類目和關鍵字推廣以及淘客報表查詢等功能.常見的淘客問題，請看該文檔的「功能介紹」等26種API。在微博，QQ，淘寶這三種中開發接口數量最多的開發平臺，開發總接口數，開放API總數多達200多個，維護管理這些API就須要不少技巧，這也是淘寶API比較奇葩的一種緣由。
http://gw.api.taobao.com/router/rest?sign=5029C3055D51555112B60B33000122D5&timestamp=2013-05-06+13%3A52%3A03&v=2.0&app_key=test&method=taobao.user.seller.get&format=xml&session=test&fields=nick
以上是淘寶API調用的主要方式，以上參數說明以下

名稱	類型	是否必須	描述
method	string	Y	API接口名稱
timestamp	string	Y	時間戳，格式爲yyyy-mm-dd HH:mm:ss，例如：2013-05-06 13:52:03。淘寶API服務端容許客戶端請求時間偏差爲6分鐘。
format	string	N	可選，指定響應格式。默認xml,目前支持格式爲xml,json
app_key	string	Y	TOP分配給應用的AppKey ，建立應用時可得到
v	string	Y	API協議版本，可選值:2.0。
sign	string	Y	對 API 輸入參數進行 md5 加密得到，詳細參考以下 3、簽名sign
sign_method	string	Y	參數的加密方法選擇，可選值是：md5,hmac
session	string	N	TOP分配給用戶的SessionKey(或 Access Token），經過登錄受權獲取，方法參考用戶受權介紹。API 文檔上「API用戶受權類型」標識爲「須要」的，調用時均要傳該參數

說淘寶開放接口是奇葩的緣由在於，http://gw.api.taobao.com/router/rest?在這個請求URL中，加了一個rest，難倒非要在URL中加上一個rest字樣纔算是REST麼？
其次，淘客API有個router概念，全部的請求通過router轉發處理，經過method控制router，全部的資源請求都是URL，而違法REST中的資源的要求。
再次，淘寶有些接口中有一個Session字段，用於傳遞用戶受權狀態，這是一種嚴重違REST的方式。
QQ的API。
        訪問連接：http://wiki.open.qq.com/wiki/API%E5%88%97%E8%A1%A8
        QQ的API涉及用戶信息類API,關係鏈類API，應用推廣類API,營銷類API，基礎支持類API等，QQ的API最糾結，一種是經過接口得到數據方式
http://openapi.tencentyun.com/v3/user/get_info
         另一種是所謂的前端js接口，經過包括qq的跨域js文件，實現js的彈窗處理。：http://fusion.qq.com/fusion_loader?appid=[應用ID]&platform=[平臺代碼]
         QQ的開發平臺，已經升級到v3版本，明顯快於淘寶的（v1，淘寶已經放棄了對v的升級），微博的v2。QQ這方面的接口已經和微信的接口屬於一個等級上，而且REST的定義方式，更優於微博，一方面是使用v3的方式，另一方面也去掉了微博上的.json後綴，這是值得確定的方式。提及來最糾結是，js接口調用方式，開發受權沒有作好，採用js方式，作安全受權。
         綜述，從REST角度來講微博，淘寶，QQ這三種開發平臺，微博作的2，可是最好，QQ最糾結，可是進步明顯，淘寶最奇葩，違反REST約束。

REST常見問題問答
         Q：使用cookie算不算是REST?
         A：REST架構風格是有一條是服務器端是無狀態的，cookie的方式，用於在記錄客戶端狀態時，這時候是符合REST風格的。Cookie的問題在於，一旦種上Cookie，在全部的請求中都會帶上Cookie信息，這種脫離請求上下文的Cookie，這會使得通訊的兩端都產生混淆使用。是非REST方式的。REST應用，web 服務是無狀態的，而應用是有狀態的。
         Q：使用Session算不算REST？
         A：應用一旦使用Session，直接違反了REST中的web服務中無狀態性，是非REST。
         Q：開發平臺上的url常見的有v和format參數，爲何要有這兩個參數？是否符合REST規範？
         A：開發平臺中v和format參數，是因爲REST先天不足的缺點致使的，經過v控制版本，能夠作系統升級時，向下兼容。format參數用於要求服務器返回特定表述，這兩種能夠在參數中約束，可是不是好方法，比較好的方法是，使用HTTP協議中的Accept，告訴客戶端所須要的格式，和版本號，以下
」Accept: application/xml」
」Accept: application/xml verson=1.0」
         Q：開發平臺上的sign旨在解決什麼問題？
         A：REST在安全方面先天不足，不像SOAP同樣，有一組WS-*協議，保證請求的安全性。因爲REST沒有這方面的標準，因此，只能從參數傳遞上作些技巧考慮，如sign加簽名的方式，簽名方式通常爲參數組合字典排序，而後組合上用戶申請的密鑰，進行下md5，生成密鑰，web服務上採用相同方式，進行驗證，確保調用安全，對REST而已，有點小牛拉大車感受，像Facebook作了更多的嘗試，好比Facebook的圖API。
         Q：瀏覽器不支持http協議中的delete，update方法怎麼辦？
       A：瀏覽器默認操做都是GET方式的，支持post方式能夠從form表單中設置，而想delete和update方式，可使用ajax進行請求處理。

綜述：

         表徵狀態轉移（英文：Representational State Transfer，簡稱REST）是Roy Fielding博士在2000年他的博士論文中提出來的一種軟件架構風格。目前在三種主流的Web服務實現方案中，由於REST模式的Web服務與複雜的SOAP和XML-RPC對比來說明顯的更加簡潔，愈來愈多的web服務開始採用REST風格設計和實現。
         REST 從資源的角度來觀察整個網絡，分佈在各處的資源由URI肯定，而客戶端的應用經過URI來獲取資源的表徵。得到這些表徵導致這些應用程序轉變了其狀態。隨着不斷獲取資源的表徵，客戶端應用不斷地在轉變着其狀態，所謂表徵狀態轉移（Representational State Transfer）須要注意的是，REST是設計風格而不是標準。REST一般基於使用HTTP，URI，和XML以及HTML這些現有的普遍流行的協議和標準。
    資源是由URI來指定。
    對資源的操做包括獲取、建立、修改和刪除資源，這些操做正好對應HTTP協議提供的GET、POST、PUT和DELETE方法。
    經過操做資源的表現形式來操做資源。
    資源的表現形式則是XML或者HTML，取決於讀者是機器仍是人，是消費web服務的客戶軟件仍是web瀏覽器。固然也能夠是任何其餘的格式。

REST的要求
    客戶端和服務器結構
    鏈接協議具備無狀態性
    可以利用Cache機制增進性能
    層次化的系統
     隨需代碼 -Javascript （可選）

REST方式優勢：
    1:能夠利用緩存Cache來提升響應速度
    2:通信自己的無狀態性可讓不一樣的服務器的處理一系列請求中的不一樣請求，提升服務器的擴展性
    3:瀏覽器便可做爲客戶端，簡化軟件需求
    4:相對於其餘疊加在HTTP協議之上的機制，REST的軟件依賴性更小
    5:不須要額外的資源發現機制
    6:在軟件技術演進中的長期的兼容性更好
     簡單來說就是，輕量級的解決方案，沒必要向SOAP那樣要構建一個標準的SOAP XML，可讀性比較好:能夠把URL的名字取得有實際意義，不須要SDK支持：直接一個Http請求就能夠，能夠在AJAX中很好使用。
REST的缺點？
        REST的優勢是輕量級解決方案，缺點就是在複雜的應用中，構造的URL會很長，影響人對URL的理解，不適合複雜應用。REST不能支持事務。在安全應用中，REST方式先天不足，須要後期策略補救。因爲REST是一種架構風格，不是一個標準，加上每一個人理解差別，形成REST不能很好統一，規範困難。
         符合REST架構風格，必然有較好的軟件擴展性，向下兼容性，可是徹底符合REST，對於如今的web服務來講，也是一項沉重的負擔，處理數據的增刪改查，會比如今麻煩的多。不管黑貓白貓抓住老鼠就是好貓，關鍵是可以解決實際問題，TOP API解決了淘寶開發平臺的問題，微博，QQ同時解決了本身開發平臺問題，同時這些開發平臺都提供了，本身的SDK包，方便調用這些接口，其實unREST is new REST。做爲超過1W字的文章，最後結論是unREST is new REST，您確定不知足，你們須要瞭解的是實際開發中如何使咱們的工做更加REST化，
1：拒絕Session
2：有限使用Cookie
3：URL中避免使用動詞，好比get，put，do之類的，儘可能使用名詞，表示資源狀態。
4：在同一url分別處理get，post請求。
補充：
         RESTful：RESTful Web 服務（也稱爲 RESTful Web API）是一個使用HTTP並遵循REST原則的Web服務，好比淘寶，騰訊，微博的開發平臺就可說是提供RESTFul Web服務。
轉帖註明：http://blog.csdn.net/ugg
參考資料：
《Architectural Styles and the Design of Network-basedSoftware Architectures？做者Roy Thomas Fielding，首次在這邊論文中提到REST，REST之父，HTTP協議的主要做者之一。
《架構風格與基於網絡的軟件架構設計》是《Architectural Styles and the Design ofNetwork-based Software Architectures》譯者爲李錕、廖志剛、劉丹、楊光。其中李錕（ ajaxcn.org 網站站長）、廖志剛( 91yee 翻譯社區負責人)、劉丹（ Matrix 技術社區負責人）、楊光（《重構與模式》的譯者）以上幾位都是互聯網資深人士，翻譯質量有保障。
白話REST-識別真假REST，http://download.csdn.net/detail/ugg/5576261
維基百科-REST： http://zh.wikipedia.org/zh-cn/REST ，以及相關資料
深刻淺出REST： http://www.infoq.com/cn/articles/rest-introduction/
對於REST中無狀態(stateless)的一點認識：http://developer.51cto.com/art/200906/129424.htm
nobody-understands-rest-or-http ：blog.steveklabnik.com/2011/07/03/nobody-understands-rest-or-http.html
RESTFUL API 設計開發:http://wenku.baidu.com/view/277d37d484254b35eefd347d.html
REST介紹與REST在PHP中的應用: http://www.nowamagic.net/librarys/veda/detail/1247
理解RESTful架構： http://www.ruanyifeng.com/blog/2011/09/restful.html
設計 REST 風格的 MVC 框架： http://www.ibm.com/developerworks/cn/java/j-lo-restmvc/
REST架構： http://www.jdon.com/tags/1109/15 通俗易懂，對於容易混淆的概念講解透徹
REST真相： http://www.jdon.com/36743
REST，Web 服務，REST-ful 服務： http://www.ibm.com/developerworks/cn/webservices/ws-RESTservices/
REST，Web 服務，REST-ful 服務： http://www.ibm.com/developerworks/cn/webservices/ws-restful/
基於 REST 的 Web 服務： http://www.ibm.com/developerworks/cn/webservices/ws-restful/
使用 WSDL 2.0 描述 REST Web 服務： http://www.ibm.com/developerworks/cn/webservices/ws-restwsdl/
最佳實踐：更好的設計你的 REST API： http://www.ibm.com/developerworks/cn/web/1103_chenyan_restapi/
REST_百度百科： http://baike.baidu.com/view/1077487.htm
REST會是SOA的將來嗎？ http://www.infoq.com/cn/articles/RESTSOAFuture/ 解答有關REST的十點疑惑 http://tech.sina.com.cn/s/s/2008-05-29/0936675195.shtml