RESTful vs基於SOAP的Web服務？

Question

我最近通過web服務手冊介紹了基於SOAP的Web服務和REST風格的Web服務。 我不確定我應該選擇哪一個參數，因爲它們看起來都相似（即使從開發人員的角度來看）。這裏是我的要點

在SOAP web服務中，我們使用由webservices生成的WSDL文件，然後基於此創建客戶端存根。

我的理解是，內部存根也會使用HTTP協議 與遠程java webservice進行通信。對？

這裏會有HTTP請求/響應正文中的SOAP消息（XML消息）。因此在基於REST的Web服務中需要多一層的深層查詢，HTTP請求本身就像消息一樣。這裏我們有WADL而不是WSDL。這裏我們也可以創建基於WADL的存根。所以每件事看起來差不多，除了一些技術上的差異 消費者連接到生產者以及如何處理請求/響應。根據我的理解，從開發人員的角度來看，基於rest和soap的web服務沒有太大的區別（開發人員的工作量幾乎相同）。

我的理解是否正確？

可能在幕後，SOAP可能比REST web服務複雜得多，因爲SOAP中有消息（SOAP消息嵌入在HTTP請求中），但在基於REST的服務中，HTTP請求本身作爲消息。

Answer 1

SOAP和REST旨在解決一組相同的問題，即以最簡單的方式促進異構應用程序之間的交互。現在是否選擇REST或SOAP不僅取決於開發工作量。你應該考慮的一些以下因素爲好，

1. 的數據類型是否它只是簡單的對象（如名值對）或非常複雜的架構（或一些二進制數據）的應用程序之間進行交換。
2. 消費者您的服務。例如。當您開發RIA時，REST更適合。
3. 安全要求。 SOAP由標準驅動，提供了一個非常好的安全性方面的穀物級調整。您可以對SOAP xml消息的各個元素進行編碼。這些類型的東西在REST中是不可能的（目前爲止）。
4. 像這樣的現在的符號JSON在輕量級數據交換中非常流行，許多REST服務框架非常容易提供這種開箱即用的功能。
5. 從技術上講，您不需要任何框架等來創建REST Web服務。據我所知，WADL等最近引入了標準化元素，但REST甚至在WADL出現之前就已存在。 REST不是什麼新鮮事，它的網絡工作方式。 REST框架使其非常簡單。

SOAP是由標準驅動的，因此在使用它們時存在更多的約束條件。所以如果你的用例很簡單（那麼這很主觀），去REST。

Answer 2

沒有什麼大的區別（特別是從開發者的角度來看）。

唯一真正的區別在於SOAP是使用WS- *建議標準化的。同樣在SOAP中，可以創建事務並根據標準保護消息本身。因此，爲了互操作性，SOAP在此基礎上具有優勢。

Answer 3

這是開發Web服務的兩種不同方式......並且關於它們的差異（和優點）有很多討論。

SOAP Web服務遠不止您提到的要點，實際上有一個完整的「堆棧」（WS- *），旨在標準化設計和實現此類Web服務的方法。這對一些系統來說很好，但對其他系統來說「太多」並且很重。在幕後HTTP是「傳輸」消息的一種流行方式，但它不是唯一的方式，它們可以通過其他協議來實現。在SOAP中，您很大程度上依賴於「WSDL」規範，該規範確實可用於「生成」服務器和客戶端代碼。在這些規範中，您非常關注「操作」，即要在Web服務上完成的事情。

另一方面，對於REST，我們更多地考慮「資源」（由給定的URI描述），然後在其上執行HTTP操作。雖然WADL存在，但SOAP Web服務中沒有太多的規範概念。實際上，一個很大的區別，以及哪些人不太瞭解（但實際上是REST原則的核心部分），REST中有一個所謂的「超鏈接」，旨在允許客戶端 - 服務器進行通信「狀態」（下一步要去哪裏），這在SOAP Web服務中不是「動態」處理的。對於開發人員來說，底線是：SOAP確實有很多好的工具（例如：所有的Eclipse Web服務工具），但是它往往有點繁瑣和很多「代碼」。 REST開發通常更清潔和更簡單。我確實認爲這兩種解決方案都是作爲你正在處理的情況的功能使用的，你不應該「挑選一個」。例如，如果您擁有龐大的企業應用程序，有很多部件和相互依賴性，事務處理等，可能還需要WSDL（合同）的SOAP Web服務。另一方面，如果您將一個Web服務（或API）暴露給客戶端，而沒有很多相互依賴關係，則可能REST是最有趣的（您可以在過去5年左右的變化中看到這一點，所有主要Web APIS - 谷歌，微博等，現在都作爲REST Web服務公開）。