大家對REST的認識？
談到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約束的來源
數據流風格（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結構爲
- 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擴展），調用一個SOAP
- 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協議 ，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的方式已經很少了。
REST與SOA對比
SOA面向服務的體系結構（Service-oriented architecture）是構造分佈式計算的應用程序的方法。它將應用程序功能作爲服務發送給最終用戶或者其他服務。
SOA採用開放標準、與軟件資源進行交互並採用表示的標準方式，SOA是一個組件模型，它將應用程序的不同功能單元（稱爲服務）通過這些服務之間定義良好的接口和契約聯繫起來。接口是採用中立的方式進行定義的，它應該獨立於實現服務的硬件平臺、操作系統和編程語言。這使得構建在各種這樣的系統中的服務可以以一種統一和通用的方式進行交互。
參考SOA面向服務器的體系架構的定義，和REST的面向資源的體系架構（ROA）對比，發現兩者有不少相同點，比如
1、統一的服務契約接口與服務接口。
2、鬆散的耦合。
3、只要有權限都可以進行訪問
REST與SOA的不同點
1、REST風格下的，只有一種協議，那就是HTTP。而SOA有多種協議，比如：TCP、HTTP等多種協議
2、使用方式上的不同。REST只要客戶端能夠模擬HTTP請求，通過標準的HTTP動作，都可以進行訪問。
3、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的對比，我們繪製如下關係圖
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×tamp=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
版權聲明：本文爲博主原創文章，未經博主允許不得轉載。
