淺談 SOAP Webserver 與 Restful Webserver 差別

原文位址：http://www.cnblogs.com/hyhnet/archive/2016/06/28/5624422.html

一　　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風格的接口，其實都是在學其形，不知其心，最後弄得不倫不類，性能上不去，安全又保證不了，徒有一個看似象摸象樣的皮囊。