本文章是由機器翻譯。

服務站

更多在 REST

Jon Flanders

內容

這是較佳，REST 或 SOAP？
安全性呢？不 SOAP 比 REST 更安全嗎？
交易呢？
交互操作性呢？SOAP 不應該是有關交互操作性吗？不比 REST 更互通性的 SOAP 嗎？
但中繼資料呢？所以如果 REST 是因此互通性，有沒有 WSDL 以 REST，而沒有 WSDL，我無法產生用戶端 Proxy 來呼叫服務。REST 很難使用。
如果想要使用非 HTTP 傳輸吗？
之後所有的資訊不您告訴 REST 適用於網際網路面向的應用程式和 SOAP 企業應用程式嗎？
底端列

最後兩個資料行中, 我已說明 REST 的基本概念，並討論有關公開和取用網頁摘要。在此的資料行中我將會回答一些通常提供讓您的簡報或進行使用 REST 建置服務為基礎的應用程式的訓練工作階段時的問題。

這是較佳，REST 或 SOAP？

這是最常見的問題，我收到關於 REST，之一，而且很少公平，可能。REST 和 SOAP 通常稱為 「 Web 服務]，」 和一個通常用來取代其他，但完全不同的方法。REST 是建置用戶端與伺服器應用程式的架構樣式。SOAP 是兩個端點之間交換資料的通訊協定規格。

比較 REST 以建立用戶端與伺服器應用程式的遠端程序呼叫 (RPC) 樣式會更精確。RPC 是樣式 (而不是一個通訊協定是 SOAP 是) 的建置用戶端與伺服器應用程式中 (通常是從中繼資料產生) Proxy 會在用戶端的位址空間中用來與伺服器進行通訊和 Proxy 的介面模擬伺服器的介面。雖然 SOAP 不需要 RPC 樣式，針對大部分現代的 SOAP 工具套件 (至少它們預設為) 使用 RPC。

相較之下，RPC，REST 缺少中繼資料產生 Proxy (請參閱下一個問題如需詳細資訊) 表示用戶端是小於結合至服務。而且，因為 REST 依賴 HTTP 的語意，資料 (GET 要求) 的要求可以快取。RPC 系統通常會有這類的基礎結構 (和即使執行 RPC over HTTP 使用 SOAP，SOAP 回應不會快取因為 SOAP 使用 HTTP POST 動詞命令會被視為不安全)。SOAP 刻意 eschews HTTP，特別為允許透過其他的通訊協定工作，使其實際呼叫以 SOAP 為基礎的服務 Web 服務有點 disingenuous SOAP。

我的觀點來看是 REST 和 SOAP 可以用來實作類似的功能但時所需的 SOAP 特定功能，並 REST 的優點讓通常最好的選擇否則通常應該使用 SOAP。

安全性呢？ 不 SOAP 比 REST 更安全嗎？

答案是沒有清楚，因為這個問題接觸到我的寵物 peeves 的其中一個。很只為容易讓 RESTful 服務安全，因為它是使以 SOAP 為基礎的服務的安全。在大多數情況下 REST 或 SOAP，安全系統都一樣： 某種形式的 HTTP 為主的驗證及安全通訊端層 (SSL)。雖然技術上的安全對話透過 HTTP 技術現在稱為傳輸層安全性 (TLS)，SSL 仍是最常使用的名稱。

什麼是，則為 True 是以 SOAP 為基礎服務因為額外的通訊協定的指定中，各種 WS-* 規格，並支援訊息的端對端安全性。這表示如果您傳遞 SOAP 訊息端點端點到端點上相同或不同通訊協定，, 則是安全。如果您的應用程式需要此特定] 功能 SOAP 再加上 WS-* 是絕對的到的方法。REST 可能不是這裡的選項的它依賴 HTTP，因為，本質上您要設計 「 多重通訊協定的應用程式。我相信事實上，SOAP 與 WS-* 啟用端對端訊息層級的安全性是以 SOAP 為基礎的服務會比 RESTful 服務更安全，misconception 的來源。

另一個區域的 「 WS-* 同仁花了很多時間，努力最近聯盟的安全性。聯盟識別背後簡單的概念是建立一家公司已驗證的使用者可以信任和被視為兩個公司間的信任經過其他公司，而不必維護驗證資訊的第二個公司 (使用者名稱及密碼，通常)。在各種 WS-* 規格實作所有主要的廠商，且 Microsoft 整合 Active Directory 透過 Active Directory 聯盟服務 (ADFS) 的意見。

中的聯盟的安全性，WS-領域 * 競技場肯定有更多的標準，比 RESTful 競技場 (和可能永遠這仍是大小寫)，但有支援聯盟的安全性，在 REST 的世界中的工作。OpenID 是一個這類工作。.NET 服務匯流排 (Windows Azure 的一部份) 也會包含聯盟的識別服務的運作方式也只是與 HTTP (因此 REST) 的並以 SOAP 為基礎的服務。

交易呢？

以下是另一個區域的 SOAP 與 WS-* 有明確的 「 進階的功能的支援且 REST 有無。WS 不可部分完成的交易支援分散式、 兩階段交易認可的交易式語意，透過 SOAP 為基礎的服務。REST 有不支援分散式交易。

通常就說如果您想交易像 RESTful 系統中，您會建立新的資源。(建立新的資源，只要您遭遇到問題 RESTful 系統通常解決大部分的問題)。 您可以有一個稱為交易的資源。當您的用戶端需要進行交易式 (例如，傳送兩個銀行帳戶之間的金錢) 時，用戶端會建立指定所有正確的資源 (在我範例，兩個銀行帳戶) 受到執行交易工廠 URI 至一個 POST 交易資源。然後用戶端可以藉由傳送一個 PUT 交易 URI 執行更新，並關閉交易將刪除傳送至的 URI。

這的就說需要您的系統手動撰寫程式碼和明確控制某些數量而 WS 不可部分完成的交易系統是更自動的因為它 (的情況下 Windows 通訊基礎) 繫結執行階段的配管。

如果您的系統絕對需要跨不同系統的不可部分完成的交易式語意，WS 不可部分完成的交易可能是到的方法。以這種方式使用分散式的交易可能或不可能智慧因為它會增加，兩個系統之間的結合性，並產生潛在的問題，如果您沒有控制兩端的程式碼。但最重要的是要為右工作使用 [右] 工具 (一旦您已知道什麼正確工作)。

防禦的 REST 我認為因此緊密地使用分散式的交易可能不是最佳的設計是公平的說出該指定的今天的分散式服務導向架構、 結合兩個結束點。在另一方面，某些情況下呼叫這種類型的功能，並如果您需要使用 SOAP 和 WS 不可部分完成的交易。

交互操作性呢？ SOAP 不應該是有關交互操作性吗？ 不比 REST 更互通性的 SOAP 嗎？

如果您定義為兩個 divergent 端點之間通訊技術能力的交互操作性，我判斷提示 REST hands 下贏得交互操作性場戰役。

因為其中一個推動點後建立 SOAP 規格來建立不同的平台和不同的語言之間進行通訊的互通性方法，很多人會訝異由這個判斷提示。但很有趣的事情發生在廣泛互通性： 「 WS-* 規格 (及該規格的廠商實作) 進行 SOAP 服務較少的互通性而非更互通性。

問題 SOAP 與 WS-* 競技場為不同的標準大量 (且每個這些標準的版本)，可從中選擇。並選擇實作特定的標準特定供應商時, 該廠商通常提供的實作，只是有點不同於其他廠商的 (或其他)。這會導致問題時要跨越廠商界限 (語言和作業系統)。

若的就說甚至要使用 SOAP 您需要 SOAP 工具組在您的平台上的大部分 (但並非全部) 的平台今天有。然後您必須處理各種 WS-* 規格和算出要使用 (或不想使用)，以及如何，影響交互操作性。若要老實說，很種一個狀況了。

在平台，方面 REST 有好處，因為您只需要使用 REST (無論是在用戶端或伺服器) 的 HTTP 堆疊。因為幾乎所有的平台和裝置，請今天有，我會認為 REST 具有最寬的互通性。指定的行動裝置、 家用裝置、 POS 裝置、 DVD 的玩家及電視所有網際網路連線能力，有越來越多的有完整的 SOAP 工具組是不可能或不可能的平台。而且如果即使您已經有一個 SOAP 工具組的特定平台，使用另一個平台的實作它的機會不 100%。

但中繼資料呢？ 所以如果 REST 是因此互通性，有沒有 WSDL 以 REST，而沒有 WSDL，我無法產生用戶端 Proxy 來呼叫服務。 REST 很難使用。

很則為 True 在世界的 REST，沒有產生用戶端從伺服器端產生的中繼資料不直接支援有是在 SOAP 與 Web 服務描述語言 (WSDL) 的世界中。數個工作所都會套用至這類支援進入 REST 一個被稱為 WADL (Web 應用程式描述語言) 為平行規格。另一個是要用以描述 RESTful 端點的 WSDL 2.0 發送。我常說 REST 簡單，但簡單不總是表示簡單。SOAP 是容易 (因為 WSDL) 但簡單不一定表示簡單。

是，使用 WSDL 可產生比撰寫程式碼更容易為 SOAP 服務 Proxy 來呼叫 RESTful 的服務。但一旦您產生 Proxy，仍然有了解 API。在 WSDL 中沒有任何會告訴您哪一個方法呼叫第一個或第二個，或您是否需要任何特定順序在所有呼叫的方法。這些是您要找出您產生 Proxy 並是原型使用服務程式碼之後的所有項目。

建置 RESTful 服務對用戶端，表示您會學習服務以及建置用戶端時，它的運作方式。一旦您完成的服務、 它的資源和互動，您可以使用這些資源的瞭解。給我，這是一大優點。因為 RESTful 服務依照 REST 的條件約束 (至少它們應該)，沒有一個慣例，您可以輕鬆地按照您決定服務的不同部份。

而且，出的開發人員片土地，wilds 中大部分的服務會包裝在項目通常稱為 「 服務代理程式，"這是另一層間接取值，用戶端防止服務層中的變更。這可能需要在 REST 或 SOAP。

另一個點就是中繼資料產生的 Proxy 什麼 SOAP 用來獲得開 RPC 紀元，也就是本機遠端投影片中的一部份。有符合在伺服器上的 API 的用戶端上的 API 的概念視為是不正確的作法，但這完全什麼樣的大部分以 SOAP 為基礎的服務。有 REST 中繼資料產生的 Proxy 也會減少運用 hyperlinking 的機會。使用超文字的應用程式狀態，引擎 (HATEOAS) 屬於 REST 的條件約束，使用它需要更鬆散聯繫的用戶端 API。

我會使最後一個點是支援 REST 變得更是以無所不在的建置用戶端將會更容易更容易。如果您查看Windows 通訊基礎 (WCF) REST 入門套件它包含這個方向往的設備。新 HttpClient API 會使用 HTTP 比使用.NET WebRequest/WebResponse API 更容易。而且，沒有新貼上為可序列化的 XML 工具可讓您複製一種 XML (例如從 RESTful 端點的文件)，並產生.NET 型別表示可以在您的應用程式中的 XML 執行個體。這很類似 WCF 工具做些什麼自動整個服務的 WSDL。經過一段時間，這些工具將會變成更複雜的使用 RESTful 服務時，進一步簡化 WCF 中的用戶端經驗。

如果想要使用非 HTTP 傳輸吗？

常見的 (有些 sarcastic) 回應從 REST 社群是、"繼續進行到，沒有任何停止您的項目。 實際的但是，REST 目前限於 HTTP，如果因為大部分的開發人員和小組的開發人員不需要的工程努力所需的 REST 語意上，工作時間說，TCP/IP。

一般答案是技術上是以正確的因為沒有正在停止您實作其他的通訊協定透過 REST 的概念，但直到廠商將新增的支援，找它一個奇怪的論點，大部分的。

之後所有的資訊不您告訴 REST 適用於網際網路面向的應用程式和 SOAP 企業應用程式嗎？

如果您已閱讀本專欄的其餘部分，您可能可以想像我認為這個陳述式是通用，則為 False。通常我聽到這個 sentiment 之後討論缺乏明確的分散式的交易支援 REST 與 WS 不可部分完成的交易中明確的支援。我 retort 通常是像好，ASP.NET 不會有支援分散式的交易，但是意思 ASP.NET 不適用於企業？

我的重點是不是每個技術可以解決每個問題中，而且有大量的技術，不支援一般功能的人想像當他們認為的企業，但是，就是仍然企業非常有幫助。

在就其實當我認為的企業應用程式，我通常都會想到速度和擴充性 — 的其中一個主要差別 REST 和 SOAP 的擴充性。SOAP 服務是很難縮放比 RESTful 服務的就當然是其中一個原因，REST 通常選擇為架構，透過網際網路 (例如 Facebook MySpace、 Twitter 及等等) 都公開的服務。

內部企業，應用程式也經常需要以及縮放。使用 REST 表示您可以採取 HTTP 快取的優點及其他功能，像條件式 GET，縮放服務幫助。許多這些技術無法使用 SOAP 使用，因為 SOAP 使用 POST 只能透過 HTTP。

底端列

希望您讀取此資料行後，您將會認為，，答案 」 的最好，REST 或 SOAP?"是"它取決。" REST 架構樣式和 SOAP 和 「 WS-* 通訊協定有優點和缺點就是建置服務。我們在 RESTafarian 營地的 (是，我必須提供完整公開此: 我是絕對的營地) 相信對於大部分的服務情況 REST 提供更多的優點比 SOAP 或 WS-*。另一方面，SOAP 和 WS-* 有一些簡單的 (和可能的) 的功能來實作使用 REST。當您需要這些特定的功能時，您一定想要使用執行階段，並可提供這些功能的工具套件。雖然此資料行不是特別的相關 WCF，採用 WCF 的一個不錯的功能是它支援 SOAP/WS 和 REST 為 *。兩個世界之間來回移動變得更容易，如果您有一個程式設計和執行階段模型，以了解。

您的問題和以的意見sstation@microsoft.com.

Jon Flanders 是獨立的顧問、 演講者和 Pluralsight 的訓練。他會指定在 BizTalk Server]、 [Windows 工作流程基礎，] 和 [Windows 通訊基礎。您可以連絡瓊在masteringbiztalk.com/blogs/jon.