介面，強大，簡單，交互，跨越平臺 下麵簡單闡述這兩大介面思想 一 REST： REST是一種架構風格，其核心是面向資源，REST專門針對網路應用設計和開發方式，以降低開發的複雜性，提高系統的可伸縮性。 REST提出設計概念和準則為： 1.網路上的所有事物都可以被抽象為資源(resource) 2.每 ...
介面，強大，簡單，交互，跨越平臺
下麵簡單闡述這兩大介面思想
一 REST：
REST是一種架構風格，其核心是面向資源，REST專門針對網路應用設計和開發方式，以降低開發的複雜性，提高系統的可伸縮性。
REST提出設計概念和準則為：
1.網路上的所有事物都可以被抽象為資源(resource)
2.每一個資源都有唯一的資源標識(resource identifier)，對資源的操作不會改變這些標識
3.所有的操作都是無狀態的
REST簡化開發，其架構遵循CRUD原則，該原則告訴我們對於資源(包括網路資源)只需要四種行為：創建，獲取，更新和刪除就可以完成相關的操作和處理。您可以通過統一資源標識符（Universal Resource Identifier，URI）來識別和定位資源，並且針對這些資源而執行的操作是通過 HTTP 規範定義的。其核心操作只有GET,PUT,POST,DELETE。
由於REST強制所有的操作都必須是stateless的，這就沒有上下文的約束，如果做分散式，集群都不需要考慮上下文和會話保持的問題。極大的提高系統的可伸縮性。
二 SOAP
SOAP偏向於面向活動，有嚴格的規範和標準，包括安全，事務等各個方面的內容。
SOAP強調操作方法和操作對象的分離，有WSDL文件規範和XSD文件分別對其定義。
而REST強調面向資源，只要我們要操作的對象可以抽象為資源即可以使用REST架構風格。
如何確定使用REST：
若本身只是簡單的CRUD業務操作，那麼抽象資源就比較容易。
而對於複雜的業務活動抽象資源並不是一個簡單的事情，比如校驗用戶等級，轉賬，事務處理等。
如何確定使用SOAP：
若有嚴格的規範和標准定義要求，且前期需要指導多個業務系統集成和開發的時，
因SOAP風格有清晰的規範標准定義，SOAP更適合。
我們可以在開始和實現之前就嚴格定義相關的介面方法和介面傳輸數據。
一句話：
簡單數據操作，無事務處理，開發和調用簡單使用REST架構風格較好。
再者：
REST核心是url和麵向資源，url代替了原來複雜的操作方法。
REST允許我們通過url設計系統，就像測試驅動開發使用測試用例設計類介面一樣。
所有可以被抽象為資源的東西都可以使用RESTful的url。
REST關鍵：
使用REST的關鍵是如何抽象資源，抽象的越精確，對REST的應用越好。
———————————————————————————————————————
三 REST思想
1．面向資源的介面設計
所有的介面設計都是針對資源來設計的（包括操作也是一種資源）。
URI的設計也是體現了對於資源的定位設計。
2．抽象操作為基礎的CRUD
Http中的get,put,post,delete分別對應了read,update,create,delete四種操作
如果僅僅是作為對於資源的操作，抽象成為這四種已經足夠了，但是對於複雜的業務介面，未必能夠滿足。
完全按照REST的思想來設計，那麼適用的環境將會有限制，而非放之四海皆準的。
3．Http是應用協議而非傳輸協議
部分認為：REST的理念設計，其實是作了一套私有的SOAP協議，因此稱之為REST風格的自定義SOAP協議。
4．無狀態，自包含
介面設計都需做到這點，不僅僅是REST，也是作為可擴展和高效性的最基本的保證，SOAP也類似。
四 SOAP Webservice和RESTful Webservice的比較
1.成熟度(總的來說SOAP在成熟度上優於REST)
SOAP對於異構環境服務發佈和調用，以及廠商的支持都已經達到了較為成熟的情況。
REST國外很多大網站都發佈了自己的開發API，很多都提供了SOAP和REST兩種Web Service，
但是由於REST只是一種基於Http協議實現資源操作的思想，因此各個網站的REST實現都自有一套。
REST實現的各種協議僅僅只能算是私有協議，當然需要遵循REST的思想。
2.效率和易用性(REST更勝一籌)
SOAP協議對於消息體和消息頭都有定義，同時消息頭的可擴展性為各種互聯網的標準提供了擴展的基礎，
WS-*系列就是較為成功的規範。但是也由於SOAP由於各種需求不斷擴充其本身協議的內容，導致在SOAP
處理方面的性能有所下降。同時在易用性方面以及學習成本上也有所增加。
REST被人們的重視，其實很大一方面也是因為其高效以及簡潔易用的特性。
這種高效一方面源於其面向資源介面設計以及操作抽象簡化了開發者的不良設計，
同時也最大限度的利用了Http最初的應用協議設計理念。
同時，REST很好的融合當前Web2.0的很多前端技術來提高開發效率。
例如:很多大型網站開放的REST風格的API都會有多種返回形式（XML,JSON,RSS,ATOM）等形式。
3.安全性
SOAP在安全方面使用XML-Security和XML-Signature兩個規範組成了WS-Security來實現安全控制的，
當前已經得到了各個廠商的支持，.net ，php ，java 都已經對其有了很好的支持。
REST 開放REST風格API的網站主要分成兩種:
一種是自定義了安全信息封裝在消息中，
另外一種就是靠硬體SSL來保障,這隻能夠保證點到點的安全，如果是需要多點傳輸的話SSL就無能為力了。
安全這塊其實也是一個很大的問題。
五 應用設計與改造
我們的系統要麼就是已經有了那些需要被髮布出去的服務，要麼就是剛剛設計好的服務，但是開發人員的傳統設計思想讓REST的形式被接受還需要一點時間。同時在資源型數據服務介面設計上來說按照REST的思想來設計相對來說要容易一些，而對於一些複雜的服務介面來說，可能強要去按照REST的風格來設計會有些牽強。這一點其實可以看看各大網站的介面就可以知道，很多網站還要傳入function的名稱作為參數，這就明顯已經違背了REST本身的設計思路。而SOAP本身就是面向RPC來設計的，開發人員十分容易接受，所以不存在什麼適應的過程。總的來說，其實還是一個老觀念，適合的才是最好的
技術沒有好壞，只有是不是合適，一種好的技術和思想被誤用了，那麼就會得到反效果。REST和SOAP各自都有自己的優點，同時如果在一些場景下如果去改造REST，其實就會走向SOAP（例如安全）。
REST對於資源型服務介面來說很合適，同時特別適合對於效率要求很高，但是對於安全要求不高的場景。而SOAP的成熟性可以給需要提供給多開發語言的，對於安全性要求較高的介面設計帶來便利。所以我覺得純粹說什麼設計模式將會占據主導地位沒有什麼意義，關鍵還是看應用場景。
同時很重要一點就是不要扭曲了REST現在很多網站都跟風去開發REST風格的介面，其實都是在學其形，不知其心，最後弄得不倫不類，性能上不去，安全又保證不了，徒有一個看似象摸象樣的皮囊。
(本文結合各大博客論壇，學習，借鑒，總結而來，歡迎轉載)
