http,soap and rest

標籤：概念   func   creat   create   encode   可擴充   修改   xml-rpc   規則   

http://www.cnblogs.com/hyhnet/archive/2016/06/28/5624422.html

 

http是標準超文字傳輸通訊協定 (HTTP)。使用對參數進行編碼並將參數作為索引值對傳遞，還使用關聯的請求語義。每個協議都包含一系列HTTP請求標題及其他一些資訊，定義用戶端向伺服器請求哪些內容，伺服器用一系列HTTP響應標題和所請求的資料進行響應。HTTP-GET 使用 MIME 類型application/x-www-form-urlencoded（將追加到處理請求的伺服器的 URL 中）以 URL 編碼文本的形式傳遞其參數。 URL 編碼是一種字元編碼形式，可確保傳遞的參數中包含一致性文本，例如將空格編碼為 %20，其它符號轉換為%XX,其中XX為該符號以16進位表示的ASCII（或ISOLatin-1）值。 追加的參數也稱為查詢字串;HTTP-POST參數也是 URL 編碼的，但是，鍵/值對是在實際的 HTTP 要求訊息內部傳遞的，而不是作為 URL 的一部分進行傳遞。

 

SOAP（Simple Object AccessProtocol）簡易物件存取通訊協定 (SOAP)。它是輕型協議，用於分散的、分散式運算環境中交換資訊。SOAP有助於以獨立於平台的方式訪問對象、服務和伺服器。它藉助於XML，提供了HTTP所需的擴充。

SOAP協議規範由4個主要的部分組成。

第一部分：SOAP封裝（Envelop）定義了一個的架構（描述訊息的內容多少、誰發送、誰應當接受、處理，以及如何處理它們）。

第二部分：SOAP編碼規則（Encoding Rules）定義了可選資料編碼規則，用於表示應用程式定義的資料類型和直接圖表，以及一個用於序列化非文法資料模型統一標準。

第三部分：SOAP RPC表示（RPC Representation）定義一個遠程調用風格（請求/響應）資訊交換的模式。

第四部分：SOAP綁定（Binding）定義了SOAP和HTTP之間的綁定和使用底層協議的交換。

SOAP協議可以簡單地理解為：SOAP=RPC+HTTP+XML，即採用HTTP作為通訊協定，RPC（Remote Procedure Call Protocol - 遠端程序呼叫協議）作為一致性的調用途徑，XML作為資料傳送的格式，從而允許服務提供者和服務客戶經過防火牆在Internet上進行通訊互動。

 

REST(Representational State Transfer)一種輕量級的Web Service架構。可以完全通過HTTP協議實現。其實現和操作比SOAP和XML-RPC更為簡潔，還可以利用緩衝Cache來提高響應速度，效能、效率和易用性上都優於SOAP協議。
REST架構對資源的操作包括擷取、建立、修改和刪除資源的操作正好對應HTTP協議提供的GET、POST、PUT和DELETE方法

 

SOAP與HTTP的區別

web service相對http（post/get）由於要進行xml解析，速度可能會有所降低。 

web service完全可以被http（post/get）替代。

Restful與SOAP的區別

安全性：SOAP會好於restful

效率和易用性(REST更勝一籌)

成熟度等級(總的來說SOAP在成熟度等級上優於REST)

 

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

 

http,soap and rest