web自動化-REST風格的Web Service
REST是一種架構風格，其核心是面向資源，REST專門針對網絡應用設計和開發(fā)方式，以降低開發(fā)的復雜性，提高系統的可伸縮性。REST提出設計概念和準則為：1.網絡上的所有事物都可以被抽象為資源(resource)
2.每一個資源都有唯一的資源標識(resource identifier)，對資源的操作不會改變這些標識
3.所有的操作都是無狀態(tài)的
REST簡化開發(fā)，其架構遵循CRUD原則，該原則告訴我們對于資源(包括網絡資源)只需要四種行為：創(chuàng)建，獲取，更新和刪除就可以完成相關的操作和處理。您可以通過統一資源標識符（Universal Resource Identifier，URI）來識別和定位資源，并且針對這些資源而執(zhí)行的操作是通過 HTTP 規(guī)范定義的。其核心操作只有GET,PUT,POST,DELETE。
由于REST強制所有的操作都必須是stateless無狀態(tài)的，這就沒有上下文的約束，如果做分布式，集群都不需要考慮上下文和會話保持的問題。極大的提高系統的可伸縮性。
對于SOAP Webservice和Restful Webservice的選擇問題，首先需要理解就是SOAP偏向于面向活動，有嚴格的規(guī)范和標準，包括安全，事務等各個方面的內容，同時SOAP強調操作 方法和操作對象的分離，有WSDL文件規(guī)范和XSD文件分別對其定義。 而REST強調面向資源，只要我們要操作的對象可以抽象為資源即可以使用REST架 構風格。
如果從這個意義上講，是否使用REST就需要考慮資源本身的抽象和識別是否困難，如果本身就是簡單的類似增刪改查的業(yè)務操作，那么抽象資源就比較容易，而 對于復雜的業(yè)務活動抽象資源并不是一個簡單的事情。比如校驗用戶等級，轉賬，事務處理等，這些往往并不容易簡單的抽象為資源。
其次如果有嚴格的規(guī)范和標準定義要求，而且前期規(guī)范標準需要指導多個業(yè)務系統集成和開發(fā)的時候，SOAP風格由于有清晰的規(guī)范標準定義是明顯有優(yōu)勢的。我們可以在開始和實現之前就嚴格定義相關的接口方法和接口傳輸數據。
簡單數據操作，無事務處理，開發(fā)和調用簡單這些是使用REST架構風格的優(yōu)勢。而對于較為復雜的面向活動的服務，如果我們還是使用REST，很多時候都是仍然是傳統的面向活動的思想通過轉換工具再轉換得到REST服務，這種使用方式是沒有意義的。
正如另外一篇文章里面談到的，REST核心是url和面向資源，url代替了原來復雜的操作方法。REST允許我們通過url設計系統，就像測試驅動開發(fā) 使用測試用例設計類接口一樣。所有可以被抽象為資源的東西都可以使用RESTful的url，當我們以傳統的用SOAP方式實現的一個查詢訂單服務的時候 可以看到，這個服務首先存在輸入的查詢條件，然后才是輸出結果集。那么對于類似場景要使用REST，不可避免的會將傳統的SOAP服務拆分為一個HTTP POST操作和一個HTTP GET操作。前面是輸入，而后面是輸出。
使用REST的關鍵是如何抽象資源，抽象的越精確，對REST的應用越好。如何進行抽象，面向資源的設計和傳統的面向結構和對象設計區(qū)別，資源和對象，數據庫表之間的差別是另外一個在分析設計時候要考慮的問題。在REST分析設計中如何改變傳統的SOAP分析設計思想又是一個重要問題。
在SOA的基礎技術實現方式中WebService占據了很重要的地位，通常我們提到WebService第一想法就是SOAP消息在各種傳輸協議上交 互。近幾年REST的思想伴隨著SOA逐漸被大家接受，同時各大網站不斷開放API提供給開發(fā)者，也激起了REST風格WebService的熱潮。
SOAP
什么是SOAP，我想不用多說，google一把滿眼都是。其實SOAP最早是針對RPC的一種解決方案，簡單對象訪問協議，很輕量，同時作為應用協議可 以基于多種傳輸協議來傳遞消息（Http,SMTP等）。但是隨著SOAP作為WebService的廣泛應用，不斷地增加附加的內容，使得現在開發(fā)人員 覺得SOAP很重，使用門檻很高。在SOAP后續(xù)的發(fā)展過程中，WS-*一系列協議的制定，增加了SOAP的成熟度，也給SOAP增加了負擔。
頁:
[1]