雙方程式設計師針對需求文件的一段對話：
如果是soap協議的話能否提供一下對應的wsdl
乙方： 呃呃呃
冪等性對同乙個系統，使用同樣的條件，一次請求和重複的多次請求對系統資源的影響是一致的。簡單物件訪問協議(****** object access protocol，soap)是一種基於 xml 的協議，可以和現存的許多網際網路協議和格式結合使用，包括超文字傳輸協議(http)，簡單郵件傳輸協議(smtp)，多用途網際郵件擴充協議(mime)，基於「通用」傳輸協議是 soap的乙個優點。soap使用基於xml的資料結構和超文字傳輸協議(http)的組合定義了乙個標準的方法來使用internet上各種不同操作環境中的分布式物件。其實soap最早是針對rpc的一種解決方案，很輕量，同時作為應用協議可以基於多種傳輸協議來傳遞訊息(http,smtp等)。但是隨著soap作為webservice的廣泛應用，不斷地增加附加的內容，使得現在開發人員覺得soap很重，使用門檻很高，而且隨著需求的增長，又不得增加協議以支援安全性，這使soap變得異常龐大，背離了簡單的初衷。在soap後續的發展過程中，ws-*一系列協議的制定，增加了soap的成熟度，也給soap增加了負擔。soap 常常被稱作「web services」，這是乙個誤稱。soap 和 web 基本上說不上話。rest 提供的才是真正的基於 url 和 http 的 「web services」。相對而言，soap協議屬於複雜的、重量級的協議，當前隨著web2.0的興起，表述性狀態轉移(representational state transfer，rest)逐步成為乙個流行的架構風格。rest是一種輕量級的web service架構風格，其實現和操作比soap和xml-rpc更為簡潔，可以完全通過http協議實現，還可以利用快取cache來提高響應速度，效能、效率和易用性上都優於soap協議。rest架構對資源的操作包括獲取、建立、修改和刪除資源的操作正好對應http協議提供的get、post、put和delete方法，這種針對網路應用的設計和開發方式，可以降低開發的複雜性，提高系統的可伸縮性。rest架構尤其適用於完全無狀態的crud(create、read、update、delete，建立、讀取、更新、刪除)操作。
基於rest的軟體體系結構風格(software architecture style)稱之為面向資源體系架構(resource-oriented architecture，roa)。按照rest原則設計的軟體、體系結構，通常被稱為「rest式的」(restful)。
由於沒有類似於soap的權威性協議作為規範，因此各個**的rest實現都自有一套，也正是因為這種各自實現的情況，在效能和可用性上會大大高於soap發布的web service，但細節方面有太多沒有約束的地方，其統一通用方面遠遠不及soap。
舉個例子：假設a組織，b組織都實現了restful api來通過工號查詢人員資訊，因為沒有統一的規範。
--- a的api 可能是這樣：http://a/api/person/001--- b的api 可能是這樣：http://a/api/person/id=001http://a/api/person/soap
rest
成熟度高
低效率和易用性低高
安全性高
低原子性事務/訊息可靠性高低
.net中如何檢視wsdl
如何測試手機上的SOAP客戶端
周四晚上，服務端和客戶端的兩個同事因為soap介面的問題爭論了起來。服務端的同事認為客戶端的同事發給服務端的soap訊息的xml結構有問題，少了幾個xml節點，導致伺服器端解析出錯。而客戶端的同事認為自己在android手機上傳送的soap，是通過乙個物件發出的，物件屬性什麼的，看 是正確設定了的，...
安裝新互動英語客戶端提示找不到SOAP的解決方案
問題分析 互動的檢測系統很弱智，檢測軟體是否安裝僅靠檢測原來設定好的路徑下是否有此軟體，64位系統將32位的程式soap3.0安裝到了系統盤下的program files x86 common files裡，而互動只檢測program files common files 32位系統預設安裝至此 是...
打包乙個使用SOAP應用的客戶端需要什麼？
做完的乙個小應用，使用vc net2003開發的，呼叫c 寫的web services,一切都ok了，打包成msi，my msi had included soap3 core.msm,msxml4sys32.msm,vc user mfc71 rtl x86 msm,vc user stl71 r...