WebService的兩種方式SOAP和REST比較
阿新 • • 發佈：2019-01-02
由於第一次接觸WebService，對於很多概念不太理解，尤其是看到各個OpenAPI的不同提供方式時，更加疑惑。如google map api採用了AJAX方式，通過javascript提供API,而淘寶TOP則採用直接的HTTP+XML請求方式，最令我疑惑的是教材上講的WSDL，UDDI從沒有在這些API中出現過。現在知道了WebService原來有兩種方式，一是SOAP協議方式，在這種方式下需要WSDL,UDDI等，二是REST方式，這種方式根本不需要WSDL,UDDI等。而且REST方式現在看來是更加流行，更有前途的方式。
在SOA的基礎技術實現方式中WebService佔據了很重要的地位，通常我們提到WebService第一想法就是SOAP訊息在各種傳輸協議上互動。近幾年REST的思想伴隨著SOA逐漸被大家接受，同時各大網站不斷開放API提供給開發者，也激起了REST風格WebService的熱潮。
在收到新需求Email之前，我對REST的理解僅僅是通過半懂不懂的看了Fielding的REST博士論文，說實話當時也就是希望瞭解這麼一個新概念，對於其內部的思想只是很膚淺的瞭解了一下。
ASF的最新需求就是可能需要實現REST風格的WebService整合，因此不得不好好的去看看REST的真正思想含義以及當前各大網站的設計方式。後面所要表述的也是我這個初學者的一些看法和觀點，拋磚引玉，希望在我將REST融入到ASF之前能夠獲得更多的反饋和意見。
SOAP
什麼是SOAP，我想不用多說，google一把滿眼都是。其實SOAP最早是針對RPC的一種解決方案，簡單物件訪問協議，很輕量，同時作為應用協議可以基於多種傳輸協議來傳遞訊息（Http,SMTP等）。但是隨著SOAP作為WebService的廣泛應用，不斷地增加附加的內容，使得現在開發人員覺得SOAP很重，使用門檻很高。在SOAP後續的發展過程中，WS-*一系列協議的制定，增加了SOAP的成熟度，也給SOAP增加了負擔。
REST
REST其實並不是什麼協議也不是什麼標準，而是將Http協議的設計初衷作了詮釋，在Http協議被廣泛利用的今天，越來越多的是將其作為傳輸協議，而非原先設計者所考慮的應用協議。SOAP型別的WebService就是最好的例子，SOAP訊息完全就是將Http協議作為訊息承載，以至於對於Http協議中的各種引數（例如編碼，錯誤碼等）都置之不顧。其實，最輕量級的應用協議就是Http協議。Http協議所抽象的get,post,put,delete就好比資料庫中最基本的增刪改查，而網際網路上的各種資源就好比資料庫中的記錄（可能這麼比喻不是很好），對於各種資源的操作最後總是能抽象成為這四種基本操作，在定義了定位資源的規則以後，對於資源的操作通過標準的Http協議就可以實現，開發者也會受益於這種輕量級的協議。
自己理解的將REST的思想歸結以下有如下幾個關鍵點：
1．面向資源的介面設計
所有的介面設計都是針對資源來設計的，也就很類似於我們的面向物件和麵向過程的設計區別，只不過現在將網路上的操作實體都作為資源來看待，同時URI的設計也是體現了對於資源的定位設計。後面會提到有一些網站的API設計說是REST設計，其實是RPC-REST的混合體，並非是REST的思想。
2．抽象操作為基礎的CRUD
這點很簡單，Http中的get,put,post,delete分別對應了read,update,create,delete四種操作，如果僅僅是作為對於資源的操作，抽象成為這四種已經足夠了，但是對於現在的一些複雜的業務服務介面設計，可能這樣的抽象未必能夠滿足。其實這也在後面的幾個網站的API設計中暴露了這樣的問題，如果要完全按照REST的思想來設計，那麼適用的環境將會有限制，而非放之四海皆準的。
3．Http是應用協議而非傳輸協議
這點在後面各大網站的API分析中有很明顯的體現，其實有些網站已經走到了SOAP的老路上，說是REST的理念設計，其實是作了一套私有的SOAP協議，因此稱之為REST風格的自定義SOAP協議。
4．無狀態，自包含
這點其實不僅僅是對於REST來說的，作為介面設計都需要能夠做到這點，也是作為可擴充套件和高效性的最基本的保證，就算是使用SOAP的WebService也是一樣。
REST vs SOAP
成熟度：
SOAP雖然發展到現在已經脫離了初衷，但是對於異構環境服務釋出和呼叫，以及廠商的支援都已經達到了較為成熟的情況。不同平臺，開發語言之間通過SOAP來互動的web service都能夠較好的互通（在部分複雜和特殊的引數和返回物件解析上，協議沒有作很細緻的規定，導致還是需要作部分修正）
REST國外很多大網站都發布了自己的開發API，很多都提供了SOAP和REST兩種Web Service，根據調查部分網站的REST風格的使用情況要高於SOAP。但是由於REST只是一種基於Http協議實現資源操作的思想，因此各個網站的REST實現都自有一套，在後面會講訴各個大網站的REST API的風格。也正是因為這種各自實現的情況，在效能和可用性上會大大高於SOAP釋出的web service，但統一通用方面遠遠不及SOAP。由於這些大網站的SP往往專注於此網站的API開發，因此通用性要求不高。
ASF上考慮釋出REST風格的Web Service，可以參考幾大網站的設計（兄弟公司的方案就是參考了類似於flickr的設計模式），但是由於沒有類似於SOAP的權威性協議作為規範，REST實現的各種協議僅僅只能算是私有協議，當然需要遵循REST的思想，但是這樣細節方面有太多沒有約束的地方。REST日後的發展所走向規範也會直接影響到這部分的設計是否能夠有很好的生命力。
總的來說SOAP在成熟度上優於REST。
效率和易用性：
SOAP協議對於訊息體和訊息頭都有定義，同時訊息頭的可擴充套件性為各種網際網路的標準提供了擴充套件的基礎，WS-*系列就是較為成功的規範。但是也由於SOAP由於各種需求不斷擴充其本身協議的內容，導致在SOAP處理方面的效能有所下降。同時在易用性方面以及學習成本上也有所增加。
REST被人們的重視，其實很大一方面也是因為其高效以及簡潔易用的特性。這種高效一方面源於其面向資源介面設計以及操作抽象簡化了開發者的不良設計，同時也最大限度的利用了Http最初的應用協議設計理念。同時，在我看來REST還有一個很吸引開發者的就是能夠很好的融合當前Web2.0的很多前端技術來提高開發效率。例如很多大型網站開放的REST風格的API都會有多種返回形式，除了傳統的xml作為資料承載，還有（JSON,RSS,ATOM）等形式，這對很多網站前端開發人員來說就能夠很好的mashup各種資源資訊。
因此在效率和易用性上來說，REST更勝一籌。
安全性：
這點其實可以放入到成熟度中，不過在當前的網際網路應用和平臺開發設計過程中，安全已經被提到了很高的高度，特別是作為外部介面給第三方呼叫，安全性可能會高過業務邏輯本身。
SOAP在安全方面是通過使用XML-Security和XML-Signature兩個規範組成了WS-Security來實現安全控制的，當前已經得到了各個廠商的支援，.net ，php ，java 都已經對其有了很好的支援（雖然在一些細節上還是有不相容的問題，但是互通基本上是可以的）。
REST沒有任何規範對於安全方面作說明，同時現在開放REST風格API的網站主要分成兩種，一種是自定義了安全資訊封裝在訊息中（其實這和SOAP沒有什麼區別），另外一種就是靠硬體SSL來保障,但是這隻能夠保證點到點的安全，如果是需要多點傳輸的話SSL就無能為力了。安全這塊其實也是一個很大的問題，今年在BEA峰會上看到有演示採用SAML2實現的網站間SSO，其實是直接採用了XML-Security和XML-Signature，效率看起來也不是很高。未來REST規範化和通用化過程中的安全是否也會採用這兩種規範，是未知的，但是加入的越多，REST失去它高效性的優勢越多。
應用設計與改造：
我們的系統要麼就是已經有了那些需要被髮布出去的服務，要麼就是剛剛設計好的服務，但是開發人員的傳統設計思想讓REST的形式被接受還需要一點時間。同時在資源型資料服務介面設計上來說按照REST的思想來設計相對來說要容易一些，而對於一些複雜的服務介面來說，可能強要去按照REST的風格來設計會有些牽強。這一點其實可以看看各大網站的介面就可以知道，很多網站還要傳入function的名稱作為引數，這就明顯已經違背了REST本身的設計思路。
而SOAP本身就是面向RPC來設計的，開發人員十分容易接受，所以不存在什麼適應的過程。
總的來說，其實還是一個老觀念，適合的才是最好的
技術沒有好壞，只有是不是合適，一種好的技術和思想被誤用了，那麼就會得到反效果。REST和SOAP各自都有自己的優點，同時如果在一些場景下如果去改造REST，其實就會走向SOAP（例如安全）。
REST對於資源型服務介面來說很合適，同時特別適合對於效率要求很高，但是對於安全要求不高的場景。而SOAP的成熟性可以給需要提供給多開發語言的，對於安全性要求較高的介面設計帶來便利。所以我覺得純粹說什麼設計模式將會佔據主導地位沒有什麼意義，關鍵還是看應用場景。
同時很重要一點就是不要扭曲了REST現在很多網站都跟風去開發REST風格的介面，其實都是在學其形，不知其心，最後弄得不倫不類，效能上不去，安全又保證不了，徒有一個看似象摸象樣的皮囊。
REST設計的幾種形式
參看了幾個大型網站的REST風格的API設計，這裡做一下大致的說明：
FaceBook:
請求訊息：
在URI設計上採取了類似於REST的風格。例如對於friends的獲取，就定義為friends.get，前面部分作為資源定義，後面是具體的操作，其他的API也是類似，資源+操作，因此就算使用http的get方法都可能作了update的操作，其實已經違背了REST的思想，但是說到，其實那麼複雜的業務介面設計下，要通過RUCD來抽象所有的介面基本是不實際的。在URI定義好以後，還有詳細的引數定義，包括型別以及是否必選。
響應訊息：
有多種方式，XML,JSON。XML有XSD作為參考。有點類似於沒有Head的SOAP，只不過這裡將原來可以定義在WSDL中的XSD抽取出來了。
Flickr:
請求訊息：
http://api.flickr.com/services/rest/?method=flickr.test.echo&name=value
這裡就可以很明顯看出它所定製的REST請求其實和RPC沒有什麼太大的區別。
訊息返回：
正確處理返回
<?xml version="1.0" encoding="utf-8" ?>
<rsp stat="ok">
[xml-payload-here]
</rsp>
錯誤處理返回
<?xml version="1.0" encoding="utf-8" ?>
<rsp stat="fail">
<err code="[error-code]" msg="[error-message]" />
</rsp>
根據返回可以看出已經違背了REST的思想，還是把Http協議作為傳輸承載協議，並沒有真正意義上使用Http協議作為資源訪問和操作協議。
總的來說，只是形式上去模仿REST，自己搞了一套私有協議。
Ebay：
請求訊息：
採用xml作為承載，類似於SOAP，不過去除SOAP訊息的封裝和包頭，同時在請求中附加了認證和警告級別等附加資訊。
訊息返回：
類似於SOAP訊息，不過刪除了SOAP的封裝和包頭，同時在返回結構中增加了訊息處理結果以及版本等附加資訊。
這個很類似於當前Axis2框架的做法，將SOAP精簡，同時根據自身需求豐富了安全，事務等協議內容。
Yahoo Maps：
請求訊息：
採用REST推薦的方式，URI+Parameters。
返回訊息：
<?xml version="1.0" encoding="UTF-8"?>
<ResultSet xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="urn:yahoo:maps"
xsi:schemaLocation="urn:yahoo:maps http://local.yahooapis.com/MapsService/V1/GeocodeResponse.xsd">
<Result precision="address">
<Latitude>37.416384</Latitude>
<Longitude>-122.024853</Longitude>
<Address>701 FIRST AVE</Address>
<City>SUNNYVALE</City>
<State>CA</State>
<Zip>94089-1019</Zip>
<Country>US</Country>
</Result>
</ResultSet>
SOAP的精簡xml返回，其他資訊，例如出錯碼等資訊由Http協議頭來承載。
YouTube：
請求訊息：
可以看到對於資源操作的URI定義也是引數的一部分。
返回訊息：
<?xml version="1.0" encoding="utf-8"?>
<ut_response status="ok">
<user_profile>
<first_name>YouTube</first_name>
<last_name>User</last_name>
<about_me>YouTube rocks!!</about_me>
<age>30</age>
<video_upload_count>7</video_upload_count>
</user_profile>
</ut_response>
自定義的類SOAP訊息。
Amazon：
請求訊息：
https://Amazon FPS web service end point/?AWSAccessKeyId=Your AWSAccessKeyId
&Timestamp=[Current timestamp] &Signature=[Signature calculated from hash of Action and Timestamp]
&SignatureVersion=[Signature calculated from hash of Action and Timestamp]
&Version=[Version of the WSDL specified in YYYY-MM-DD format] &Action=[Name of the API]
¶meter1=[Value of the API parameter1] ¶meter2=[Value of the API parameter2]
&...[API parameters and their values]
返回訊息：
類似於SOAP的自有協議，訊息體中包含了訊息狀態等附加資訊。
總結：
看了上面那麼多網站的設計，總結一下主要有這麼幾種設計方式。
請求訊息設計：
1． 基本符合REST標準方式：資源URI定義（資源．操作）+引數。這類設計如果濫用get去處理其他型別的操作，那麼和2無異。
2． REST風格非REST思想：資源URI定義+引數（包含操作方法名）。其實就是RPC的REST跟風。
3． 類似於SOAP訊息，自定義協議，以xml作為承載。（可擴充套件，例如鑑權，訪問控制等），不過那就好比自己定義了一套SOAP和SOAP extends。大型的有實力的網站有的採取此種做法。
響應訊息設計：
1. REST標準方式，將Resource State傳輸返回給客戶端，Http訊息作為應用協議而非傳輸協議
2. 以XML作為訊息承載體，Http作為訊息傳輸協議，處理狀態自包含。
3. 自定義訊息格式，類似於SOAP，提供可擴充套件部分。
作為遵循REST的理念來看我的選擇是響應1和請求1的設計。
REST和ASF的整合
ASF要整合REST就現在來看有兩種比較合適的方法。
一．就是採用Axis2的REST實現，這種方式的好處就是開發週期短，容易整合，但是請求和響應的格式無法改變，資源URI設計受限，Axis2的REST其實就是將SOAP訊息精簡，請求的時候刪除了SOAP的頭，響應的時候僅僅返回資源資訊，如果提供xsd就可以被各種客戶端所解析。並非真正的REST。
二．就是採用Restlet開源框架，將Restlet開源框架整合到ASF中，由於Restlet本身就是可內嵌的應用框架，因此整合不成問題，同時Restlet框架只是API結構框架，因此實現和定義完全分開，整合Restlet以後可以自己實現其中的解析引擎也可以採用預設提供的引擎，同時對於內嵌Jetty等多種開源專案的支援，將更多優勢融入到了Rest中。看了一下國內也有很多朋友已經關注Restlet開源專案，看了它的架構設計，個人覺得還是比較靈活和緊湊的。
題外話
在寫這篇文章以前寫了一篇調研報告群發給各個架構師們參考，期待反饋。下午正好和我們的首席架構師聊了一會兒。其實我和他的感覺是一樣的，REST是否真的在我們現有的服務框架中需要整合，理解了REST的思想再去看應用場景，那麼可以發現如果要完全遵循REST的設計理念來設計介面的話，那麼強要去改變現有已經存在的或者還未開發的介面就會落入為了技術而技術，為了潮流而跟風的近地。當然並不否認REST的好，其實我們兄弟公司的一些業務場景有部分的介面十分合適這類設計，面向資源，高效，簡潔，易用都能夠體現出它的價值。我們將會和我們的兄弟公司合作，也會參考他們的設計理念，在參考當前各個網站的實現情況下，部分的採用這類形式的釋出，提供給第三方的ISV，無疑是我現在把REST融入到ASF中最好的理由。
有了需求去做才不會陷入為了技術而技術，畢竟技術是由商業價值驅動的，同樣社會上充斥著各種技術的鼓吹，如果稍不留神就會陷入跟風的潮流中。
在SOA的基礎技術實現方式中WebService佔據了很重要的地位，通常我們提到WebService第一想法就是SOAP訊息在各種傳輸協議上互動。近幾年REST的思想伴隨著SOA逐漸被大家接受，同時各大網站不斷開放API提供給開發者，也激起了REST風格WebService的熱潮。
在收到新需求Email之前，我對REST的理解僅僅是通過半懂不懂的看了Fielding的REST博士論文，說實話當時也就是希望瞭解這麼一個新概念，對於其內部的思想只是很膚淺的瞭解了一下。
ASF的最新需求就是可能需要實現REST風格的WebService整合，因此不得不好好的去看看REST的真正思想含義以及當前各大網站的設計方式。後面所要表述的也是我這個初學者的一些看法和觀點，拋磚引玉，希望在我將REST融入到ASF之前能夠獲得更多的反饋和意見。
SOAP
什麼是SOAP，我想不用多說，google一把滿眼都是。其實SOAP最早是針對RPC的一種解決方案，簡單物件訪問協議，很輕量，同時作為應用協議可以基於多種傳輸協議來傳遞訊息（Http,SMTP等）。但是隨著SOAP作為WebService的廣泛應用，不斷地增加附加的內容，使得現在開發人員覺得SOAP很重，使用門檻很高。在SOAP後續的發展過程中，WS-*一系列協議的制定，增加了SOAP的成熟度，也給SOAP增加了負擔。
REST
REST其實並不是什麼協議也不是什麼標準，而是將Http協議的設計初衷作了詮釋，在Http協議被廣泛利用的今天，越來越多的是將其作為傳輸協議，而非原先設計者所考慮的應用協議。SOAP型別的WebService就是最好的例子，SOAP訊息完全就是將Http協議作為訊息承載，以至於對於Http協議中的各種引數（例如編碼，錯誤碼等）都置之不顧。其實，最輕量級的應用協議就是Http協議。Http協議所抽象的get,post,put,delete就好比資料庫中最基本的增刪改查，而網際網路上的各種資源就好比資料庫中的記錄（可能這麼比喻不是很好），對於各種資源的操作最後總是能抽象成為這四種基本操作，在定義了定位資源的規則以後，對於資源的操作通過標準的Http協議就可以實現，開發者也會受益於這種輕量級的協議。
自己理解的將REST的思想歸結以下有如下幾個關鍵點：
1．面向資源的介面設計
所有的介面設計都是針對資源來設計的，也就很類似於我們的面向物件和麵向過程的設計區別，只不過現在將網路上的操作實體都作為資源來看待，同時URI的設計也是體現了對於資源的定位設計。後面會提到有一些網站的API設計說是REST設計，其實是RPC-REST的混合體，並非是REST的思想。
2．抽象操作為基礎的CRUD
這點很簡單，Http中的get,put,post,delete分別對應了read,update,create,delete四種操作，如果僅僅是作為對於資源的操作，抽象成為這四種已經足夠了，但是對於現在的一些複雜的業務服務介面設計，可能這樣的抽象未必能夠滿足。其實這也在後面的幾個網站的API設計中暴露了這樣的問題，如果要完全按照REST的思想來設計，那麼適用的環境將會有限制，而非放之四海皆準的。
3．Http是應用協議而非傳輸協議
這點在後面各大網站的API分析中有很明顯的體現，其實有些網站已經走到了SOAP的老路上，說是REST的理念設計，其實是作了一套私有的SOAP協議，因此稱之為REST風格的自定義SOAP協議。
4．無狀態，自包含
這點其實不僅僅是對於REST來說的，作為介面設計都需要能夠做到這點，也是作為可擴充套件和高效性的最基本的保證，就算是使用SOAP的WebService也是一樣。
REST vs SOAP
成熟度：
SOAP雖然發展到現在已經脫離了初衷，但是對於異構環境服務釋出和呼叫，以及廠商的支援都已經達到了較為成熟的情況。不同平臺，開發語言之間通過SOAP來互動的web service都能夠較好的互通（在部分複雜和特殊的引數和返回物件解析上，協議沒有作很細緻的規定，導致還是需要作部分修正）
REST國外很多大網站都發布了自己的開發API，很多都提供了SOAP和REST兩種Web Service，根據調查部分網站的REST風格的使用情況要高於SOAP。但是由於REST只是一種基於Http協議實現資源操作的思想，因此各個網站的REST實現都自有一套，在後面會講訴各個大網站的REST API的風格。也正是因為這種各自實現的情況，在效能和可用性上會大大高於SOAP釋出的web service，但統一通用方面遠遠不及SOAP。由於這些大網站的SP往往專注於此網站的API開發，因此通用性要求不高。
ASF上考慮釋出REST風格的Web Service，可以參考幾大網站的設計（兄弟公司的方案就是參考了類似於flickr的設計模式），但是由於沒有類似於SOAP的權威性協議作為規範，REST實現的各種協議僅僅只能算是私有協議，當然需要遵循REST的思想，但是這樣細節方面有太多沒有約束的地方。REST日後的發展所走向規範也會直接影響到這部分的設計是否能夠有很好的生命力。
總的來說SOAP在成熟度上優於REST。
效率和易用性：
SOAP協議對於訊息體和訊息頭都有定義，同時訊息頭的可擴充套件性為各種網際網路的標準提供了擴充套件的基礎，WS-*系列就是較為成功的規範。但是也由於SOAP由於各種需求不斷擴充其本身協議的內容，導致在SOAP處理方面的效能有所下降。同時在易用性方面以及學習成本上也有所增加。
REST被人們的重視，其實很大一方面也是因為其高效以及簡潔易用的特性。這種高效一方面源於其面向資源介面設計以及操作抽象簡化了開發者的不良設計，同時也最大限度的利用了Http最初的應用協議設計理念。同時，在我看來REST還有一個很吸引開發者的就是能夠很好的融合當前Web2.0的很多前端技術來提高開發效率。例如很多大型網站開放的REST風格的API都會有多種返回形式，除了傳統的xml作為資料承載，還有（JSON,RSS,ATOM）等形式，這對很多網站前端開發人員來說就能夠很好的mashup各種資源資訊。
因此在效率和易用性上來說，REST更勝一籌。
安全性：
這點其實可以放入到成熟度中，不過在當前的網際網路應用和平臺開發設計過程中，安全已經被提到了很高的高度，特別是作為外部介面給第三方呼叫，安全性可能會高過業務邏輯本身。
SOAP在安全方面是通過使用XML-Security和XML-Signature兩個規範組成了WS-Security來實現安全控制的，當前已經得到了各個廠商的支援，.net ，php ，java 都已經對其有了很好的支援（雖然在一些細節上還是有不相容的問題，但是互通基本上是可以的）。
REST沒有任何規範對於安全方面作說明，同時現在開放REST風格API的網站主要分成兩種，一種是自定義了安全資訊封裝在訊息中（其實這和SOAP沒有什麼區別），另外一種就是靠硬體SSL來保障,但是這隻能夠保證點到點的安全，如果是需要多點傳輸的話SSL就無能為力了。安全這塊其實也是一個很大的問題，今年在BEA峰會上看到有演示採用SAML2實現的網站間SSO，其實是直接採用了XML-Security和XML-Signature，效率看起來也不是很高。未來REST規範化和通用化過程中的安全是否也會採用這兩種規範，是未知的，但是加入的越多，REST失去它高效性的優勢越多。
應用設計與改造：
我們的系統要麼就是已經有了那些需要被髮布出去的服務，要麼就是剛剛設計好的服務，但是開發人員的傳統設計思想讓REST的形式被接受還需要一點時間。同時在資源型資料服務介面設計上來說按照REST的思想來設計相對來說要容易一些，而對於一些複雜的服務介面來說，可能強要去按照REST的風格來設計會有些牽強。這一點其實可以看看各大網站的介面就可以知道，很多網站還要傳入function的名稱作為引數，這就明顯已經違背了REST本身的設計思路。
而SOAP本身就是面向RPC來設計的，開發人員十分容易接受，所以不存在什麼適應的過程。
總的來說，其實還是一個老觀念，適合的才是最好的
技術沒有好壞，只有是不是合適，一種好的技術和思想被誤用了，那麼就會得到反效果。REST和SOAP各自都有自己的優點，同時如果在一些場景下如果去改造REST，其實就會走向SOAP（例如安全）。
REST對於資源型服務介面來說很合適，同時特別適合對於效率要求很高，但是對於安全要求不高的場景。而SOAP的成熟性可以給需要提供給多開發語言的，對於安全性要求較高的介面設計帶來便利。所以我覺得純粹說什麼設計模式將會佔據主導地位沒有什麼意義，關鍵還是看應用場景。
同時很重要一點就是不要扭曲了REST現在很多網站都跟風去開發REST風格的介面，其實都是在學其形，不知其心，最後弄得不倫不類，效能上不去，安全又保證不了，徒有一個看似象摸象樣的皮囊。
REST設計的幾種形式
參看了幾個大型網站的REST風格的API設計，這裡做一下大致的說明：
FaceBook:
請求訊息：
在URI設計上採取了類似於REST的風格。例如對於friends的獲取，就定義為friends.get，前面部分作為資源定義，後面是具體的操作，其他的API也是類似，資源+操作，因此就算使用http的get方法都可能作了update的操作，其實已經違背了REST的思想，但是說到，其實那麼複雜的業務介面設計下，要通過RUCD來抽象所有的介面基本是不實際的。在URI定義好以後，還有詳細的引數定義，包括型別以及是否必選。
響應訊息：
有多種方式，XML,JSON。XML有XSD作為參考。有點類似於沒有Head的SOAP，只不過這裡將原來可以定義在WSDL中的XSD抽取出來了。
Flickr:
請求訊息：
http://api.flickr.com/services/rest/?method=flickr.test.echo&name=value
這裡就可以很明顯看出它所定製的REST請求其實和RPC沒有什麼太大的區別。
訊息返回：
正確處理返回
<?xml version="1.0" encoding="utf-8" ?>
<rsp stat="ok">
[xml-payload-here]
</rsp>
錯誤處理返回
<?xml version="1.0" encoding="utf-8" ?>
<rsp stat="fail">
<err code="[error-code]" msg="[error-message]" />
</rsp>
根據返回可以看出已經違背了REST的思想，還是把Http協議作為傳輸承載協議，並沒有真正意義上使用Http協議作為資源訪問和操作協議。
總的來說，只是形式上去模仿REST，自己搞了一套私有協議。
Ebay：
請求訊息：
採用xml作為承載，類似於SOAP，不過去除SOAP訊息的封裝和包頭，同時在請求中附加了認證和警告級別等附加資訊。
訊息返回：
類似於SOAP訊息，不過刪除了SOAP的封裝和包頭，同時在返回結構中增加了訊息處理結果以及版本等附加資訊。
這個很類似於當前Axis2框架的做法，將SOAP精簡，同時根據自身需求豐富了安全，事務等協議內容。
Yahoo Maps：
請求訊息：
採用REST推薦的方式，URI+Parameters。
返回訊息：
<?xml version="1.0" encoding="UTF-8"?>
<ResultSet xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="urn:yahoo:maps"
xsi:schemaLocation="urn:yahoo:maps http://local.yahooapis.com/MapsService/V1/GeocodeResponse.xsd">
<Result precision="address">
<Latitude>37.416384</Latitude>
<Longitude>-122.024853</Longitude>
<Address>701 FIRST AVE</Address>
<City>SUNNYVALE</City>
<State>CA</State>
<Zip>94089-1019</Zip>
<Country>US</Country>
</Result>
</ResultSet>
SOAP的精簡xml返回，其他資訊，例如出錯碼等資訊由Http協議頭來承載。
YouTube：
請求訊息：
可以看到對於資源操作的URI定義也是引數的一部分。
返回訊息：
<?xml version="1.0" encoding="utf-8"?>
<ut_response status="ok">
<user_profile>
<first_name>YouTube</first_name>
<last_name>User</last_name>
<about_me>YouTube rocks!!</about_me>
<age>30</age>
<video_upload_count>7</video_upload_count>
</user_profile>
</ut_response>
自定義的類SOAP訊息。
Amazon：
請求訊息：
https://Amazon FPS web service end point/?AWSAccessKeyId=Your AWSAccessKeyId
&Timestamp=[Current timestamp] &Signature=[Signature calculated from hash of Action and Timestamp]
&SignatureVersion=[Signature calculated from hash of Action and Timestamp]
&Version=[Version of the WSDL specified in YYYY-MM-DD format] &Action=[Name of the API]
¶meter1=[Value of the API parameter1] ¶meter2=[Value of the API parameter2]
&...[API parameters and their values]
返回訊息：
類似於SOAP的自有協議，訊息體中包含了訊息狀態等附加資訊。
總結：
看了上面那麼多網站的設計，總結一下主要有這麼幾種設計方式。
請求訊息設計：
1． 基本符合REST標準方式：資源URI定義（資源．操作）+引數。這類設計如果濫用get去處理其他型別的操作，那麼和2無異。
2． REST風格非REST思想：資源URI定義+引數（包含操作方法名）。其實就是RPC的REST跟風。
3． 類似於SOAP訊息，自定義協議，以xml作為承載。（可擴充套件，例如鑑權，訪問控制等），不過那就好比自己定義了一套SOAP和SOAP extends。大型的有實力的網站有的採取此種做法。
響應訊息設計：
1. REST標準方式，將Resource State傳輸返回給客戶端，Http訊息作為應用協議而非傳輸協議
2. 以XML作為訊息承載體，Http作為訊息傳輸協議，處理狀態自包含。
3. 自定義訊息格式，類似於SOAP，提供可擴充套件部分。
作為遵循REST的理念來看我的選擇是響應1和請求1的設計。
REST和ASF的整合
ASF要整合REST就現在來看有兩種比較合適的方法。
一．就是採用Axis2的REST實現，這種方式的好處就是開發週期短，容易整合，但是請求和響應的格式無法改變，資源URI設計受限，Axis2的REST其實就是將SOAP訊息精簡，請求的時候刪除了SOAP的頭，響應的時候僅僅返回資源資訊，如果提供xsd就可以被各種客戶端所解析。並非真正的REST。
二．就是採用Restlet開源框架，將Restlet開源框架整合到ASF中，由於Restlet本身就是可內嵌的應用框架，因此整合不成問題，同時Restlet框架只是API結構框架，因此實現和定義完全分開，整合Restlet以後可以自己實現其中的解析引擎也可以採用預設提供的引擎，同時對於內嵌Jetty等多種開源專案的支援，將更多優勢融入到了Rest中。看了一下國內也有很多朋友已經關注Restlet開源專案，看了它的架構設計，個人覺得還是比較靈活和緊湊的。
題外話
在寫這篇文章以前寫了一篇調研報告群發給各個架構師們參考，期待反饋。下午正好和我們的首席架構師聊了一會兒。其實我和他的感覺是一樣的，REST是否真的在我們現有的服務框架中需要整合，理解了REST的思想再去看應用場景，那麼可以發現如果要完全遵循REST的設計理念來設計介面的話，那麼強要去改變現有已經存在的或者還未開發的介面就會落入為了技術而技術，為了潮流而跟風的近地。當然並不否認REST的好，其實我們兄弟公司的一些業務場景有部分的介面十分合適這類設計，面向資源，高效，簡潔，易用都能夠體現出它的價值。我們將會和我們的兄弟公司合作，也會參考他們的設計理念，在參考當前各個網站的實現情況下，部分的採用這類形式的釋出，提供給第三方的ISV，無疑是我現在把REST融入到ASF中最好的理由。
有了需求去做才不會陷入為了技術而技術，畢竟技術是由商業價值驅動的，同樣社會上充斥著各種技術的鼓吹，如果稍不留神就會陷入跟風的潮流中。