Web Service架構

     SOAP協議：簡單對象訪問協議,技術有助於實現大量異構程序和平臺之間的互操做性,根據我有限的瞭解，SOAP是把成熟的基於HTTP的WEB技術與 XML的靈活性和可擴展性組合在了一塊兒。好比咱們.NET中的WEB服務，就是基於SOAP。soap採用xml，流量會大一點，速度也會比較 慢,soap能夠經過tcp,udp,http協議來傳送。這也是讓人困惑的描述。一看這句話，就會感受http怎麼和tcp,udp協議並列了呢？難道 http仍是屬於傳輸層的協議？再加上http中文譯名的問題，名字聽上去像傳輸層，初學者又要開始頭大了。事實上，http是應用層的協議，這一點能夠 毫無懷疑。那麼如今新的問題來了。soap和http都是應用層協議，怎麼說soap能用http協議來傳輸呢？應用層的協議能夠用應用層的協議傳送 嗎？soap將信息進行XML的序列化後，再用http協議的方式再打包進行傳送，傳送的方式仍是tcp或者udp。作個比喻就好理解了。tcp 和 udp 都是公路，暫且把tcp認爲是通常公路，udp高速公路，soap和http就都是汽車，那麼soap和http均可以在tcp和udp上跑。說soap 能夠經過http來傳送，實際就是說soap是小轎車，http是裝轎車的卡車，把soap的信息裝到http裏面，而後再運輸，固然走的道路仍是tcp 或udp。說soap能夠經過http協議來傳輸，這句話不太準確，比較準確第說法是：soap信息能夠經過http協議包裝後經過tcp或udp傳輸。 REST架構對資源的操做包括獲取、建立、修改和刪除資源的操做正好對應HTTP協議提供的GET、POST、PUT和DELETE方法(Verb)。爲 什麼要學習web service？大多數對外接口會實現web service方法而不是http方法，若是你不會，那就沒有辦法對接。

web service相對http (post/get)有好處嗎？1.接口中實現的方法和要求參數一目瞭然  2.不用擔憂大小寫問題 3.不用擔憂中文urlencode問題4.代碼中不用屢次聲明認證(帳號,密碼)參數 5.傳遞參數能夠爲數組，對象等...  

web service相對http（post/get）快嗎？因爲要進行xml解析，速度可能會有所下降。 

 web service 能夠被http（post/get）替代嗎？徹底能夠，並且如今的開放平臺都是用的HTTP（post/get）實現的。SOAP會好於 restful 效率和易用性(REST更勝一籌) 成熟度(總的來講SOAP在成熟度上優於REST) 。SOAP是一種簡單基於xml的輕量協議，用戶web上交換結構化信息和類型信息。SOAP 的整體設計目標是使其儘可能簡單，並提供最低限度的功能。 該協議定義一個不包含應用程序或傳輸語義的消息傳遞框架。 所以，該協議是模塊化的且高度可擴展。經過在標準傳輸協議之上傳輸，SOAP 可使用 Internet 的現有開放式體系結構，而且容易被可以支持最基本的 Internet 標準的任意系統所接受。 能夠將支持符合 SOAP 的 XML Web services 所必需的基礎結構看做是一種很是簡單且強大的基礎結構，由於它向 Internet 的現有基礎結構添加相對較少的內容，但仍然有助於對用 SOAP 生成的服務進行通用訪問。SOAP 協議規範包括四個主要部分。第一部分定義用於封裝數據的必需的可擴展信封。SOAP 信封定義 SOAP 消息，是 SOAP 消息處理程序之間的基本交換單位。這是該規範中惟一的一個必需部分。SOAP 協議規範的第二部分定義了可選的數據編碼規則和一個統一模型，數據編碼規則用來表示應用程序定義的數據和有向圖，統一模型用來序列化非語法數據模型。第三 部分定義 RPC 樣式（請求/響應）消息交換模式。 每一個 SOAP 消息都是單向傳輸。雖然 SOAP 的根位於 RPC 中，但它並不侷限於成爲一種請求/響應機制。 XML Web services 一般組合 SOAP 消息以實現這類模式，，但對於 SOAP 而言消息交換模式並非必需的，而且這一部分規範也是可選的。規範的第四部分定義 SOAP 與 HTTP 之間的綁定。可是，這部分也是可選的。 能夠將 SOAP 與任何能夠傳輸 SOAP 信封的傳輸協議或機制結合使用，其中包括 SMTP、FTP，甚至還包括軟盤。