Web Service - RESTful 和 SOAP 筆記

1.什麼是Web Service(Web服務)

從表面上看,Web Service就是一個應用程序,它向外界暴露出一個可以經過Web進行調用的API編程

這就是說,你可以用編程的方法透明的調用這個應用程序,不須要了解 它的任何細節,設計模式

跟你使用的編程語言也沒有關係。緩存

例如能夠建立一個提供天氣預報的Web Service,那麼不管你用哪一種編程語言開發的應用,均可以經過調用它的API並傳入城市信息來得到該城市的天氣預報。安全

之因此稱之爲Web Service,是由於它基於HTTP協議傳輸數據,服務器

這使得運行在不一樣機器上的不一樣應用無須藉助附加的、專門的第三方軟件或硬件,網絡

就可相互交換數據或集 架構


2.SOA(Service-Oriented Architecture,面向服務的架構)

SOA是一種思想,它將應用程序的不一樣功能單元經過中立的契約聯繫起來,編程語言

    獨立於硬件平臺、操做系統和編程語言,使得各類形式的功能單元可以更好的集成性能

    顯然,Web ServiceSOA的一種較好的解決方案它更多的是一種標準,而不是一種具體的技術spa


3.概念解釋:SOAP、WSDL、UDDI

SOAP

簡單對象訪問協議(Simple   Object Access Protocol),

Web   Service中交換數據的一種協議規範

WSDL

Web服務描述語言(Web   Service Description Language),

它描述了Web服務的公共接口。

這是一個基於XML的關於如何與Web服務通信和使用的服務描述;

也就是描述與目錄中列出的Web 務進行交互時須要綁定的協議和信息格式。

一般採用抽象語言描述該服務支持的操做和信息,

使用的時候再將實際的網絡協議和信息格式綁定給該服務。

UDDI

統一描述、發現和集成(Universal   Description, Discovery and Integration),

它是一個基於XML的跨平臺的描述規範,

可使世界範圍內的企業在互聯網上發佈本身所提供的服務。

簡單的說,UDDI是訪問各 WSDL的一個門面(能夠參考設計模式中的門面模式)


4.Java規範中和Web Service相關的規範有哪些

Java規範中和Web Service相關的有

JAX-WS(JSR 224)

這個規範是早期的基於SOAPWeb   Service規範JAX-RPC替代版本

它並不提供向下兼容性,

由於RPC樣式的WSDL以及相關的API已經在Java   EE5中被移除了。

WS-MetaDataJAX-WS的依賴規範,

提供了基於註解配置Web   ServiceSOAP消息的相關API

JAXM(JSR 67)

定義了發送和接收消息所需的API,至關於Web   Service的服務器

JAX-RS(JSR 311

& JSR 339

& JSR 370)

是針對RESTRepresentation   State Transfer架構風格制定的一套Web Service規範
 
REST是一種軟件架構模式,是一種風格

          它不像SOAP那樣自己承載着一種消息協議

          能夠將REST視爲基於HTTP協議的軟件架構

REST最重要的兩個概念資源定位資源操做

          HTTP協議剛好完整的提供了這兩個點

          HTTP協議中的URI能夠完成資源定位,

          GETPOSTOPTIONDELETE方法能夠完成資源操做
 
所以REST徹底依賴HTTP協議就能夠完成Web   Service

          而不像SOAP協議那樣只利用了HTTP的傳輸特性

          定位和操做都是由SOAP協議自身完成的

          也正是因爲SOAP消息的存在使得基於SOAPWeb   Service顯得笨重逐漸被淘汰


5.REST和SOAP Web Service的比較

5.1什麼是SOAP?

                SOAP (Simple Object Access Protocol) 顧名思義,是一個嚴格定義信息交換協議

用於在Web Service中,把遠程調用和返回封裝成機器可讀的格式化數據。

事實上SOAP數據使用XML數據格式,

定義了一整套複雜的標籤,以描述調用的遠程過程、參數、返回值和出錯信息等等。

並且隨着須要的增加,又不得增長協議以支持安全性,

這使SOAP變得異常龐大,背離了簡單的初衷。
另外一方面,各個服務器均可以基於這個協議推出本身的API

即便它們提供的服務及其類似,定義的API也不盡相同,這又致使了WSDL的誕生。

WSDL (Web Service Description Language) 也遵循XML格式,

用來描述哪一個服務器提供什麼服務,怎樣找到它,以及該服務使用怎樣的接口規範,

簡言之,服務發現。

如今,使用Web Service的過程變成,

得到該服務的WSDL描述,

根據WSDL構造一條格式化的SOAP請求發送給服務器,

而後接收一條一樣SOAP格式的應答,

最後根據先前的WSDL解碼數據。

絕大多數狀況下,請求和應答使用HTTP協議傳輸,那麼發送請求就使用HTTPPOST方法

5.2什麼是REST

REST (REpresentational State Transfort)

形式上應該表述爲客戶端經過申請資源來實現狀態的轉換,

在這個角度,系統能夠當作一臺虛擬的狀態機

REST應該知足這樣的特色:

1)客戶端和服務器結構;

2)鏈接協議具備無狀態性

3)可以利用Cache機制增進性能;

4)層次化的系統;

5)按需代碼。

說到底,REST只是一種架構風格,而不是協議或標準

但這種風格對現有的以SOAP爲表明的Web Service形成的衝擊也是革命性的,

由於它面向資源,甚至連服務抽象成資源

由於它和HTTP緊密結合,由於它服務器無狀態

5.3RESTSOAP的區別?

即便絕大多數SOAP是運行在HTTP上,使用URI標識服務,

SOAP也僅僅使用POST方法發送請求,用一個惟一的URI標識服務的入口
      對於SOAP,delete操做也要用POST方法來發送,

而其實HTTP協議有更合邏輯的DELETE方法可用。

REST爲每個資源指定一個惟一的URI
                而用HTTP4種方法GETPOSTPUTDELETE直觀地表示
                                獲取、建立、更新和刪除圖書。

REST的優勢?
                REST簡單而直觀,把HTTP協議利用到了極限。
                                1. 它用HTTP請求的頭信息來指明資源的表示形式,
                                2. HTTP的錯誤機制來返回訪問資源的錯誤。
                                                由此帶來的直接好處是構建的成本減小了,
                                                例如用URI定位每個資源能夠利用通用成熟的技術,
                                                而不用再在服務器端開發一套資源訪問機制。
                                3. 只需簡單配置服務器就能規定資源的訪問權限,
                                                例如經過禁止非GET訪問把資源設成只讀。
                                4. 服務器無狀態帶來了更多額外好處,
                                                由於每次請求都包含響應須要的全部信息,全部狀態信息都存儲在客戶端,
                                                服務器的內存從龐大的狀態信息中解放出來。
                                                並且如今即便一臺服務器忽然死機對客戶的影響也微乎其微,
                                                由於另外一臺服務器能夠立刻代替它的位置,而不須要考慮恢復狀態信息。
                                5. 更多的緩存也變成可能,
                                                而以前因爲服務器有狀態,對同一個URI的請求可能致使徹底不一樣的響應。
                整體結果是,網絡的容錯性延展性都加強了,這些原本是WEB設計的初衷,
                                日趨複雜和定製的WEB把它們破壞了,如今REST又返璞歸真,
                                試圖把Web Service帶回簡單的原則中來。
REST的不足之處?
               
無狀態帶來了巨大的優點,同時也帶來了難以解決的問題,
                                例如,怎樣受權特定用戶才能使用的服務?怎樣驗證用戶身份?
                                若是堅持服務器無狀態,也就是不記錄用戶登陸狀態
                                勢必要求每一次服務請求都包含完整的用戶身份和驗證信息。
                                在這種狀況下,怎樣避免冒認?怎樣避免用戶信息泄漏?
                                事實上,構建REST附屬的安 全機制已經在討論中,
                                其結果無非致使另外一個SOAP:複雜的需求摧殘了易用性
     
REST面向資源的應用中左右逢源,但在面向事務的應用中卻未如人意
           
面向資源的應用操做簡單,無非建立、讀取、改變、刪除幾項,
                                可是面向事務的應用不容許用戶直接操做資源,
                                用戶只需向系統提交一個事務說明要求,而後等待事 務的完成,
                                                就如一個網上銀行的用戶不直接修改帳戶和存款,
                                                而是提交一個事務告訴銀行本身要轉帳。
                                                若是把這樣的服務當作一種資源,
                                                                經過向資源發送POST 求完成事務,那不過是SOAP的翻版而已。
                                                不管是這樣,仍是經過PUT來建立事務,
                                                                都改變了系統的狀態(資源自己未改變,此處是改變了用戶的餘額),
                                                                顯然 違背了REST直觀的初衷

相關文章
相關標籤/搜索