我知道這是一個老問題，必須已經答覆了上百次，但我還是無法找到滿意的答覆。Web服務與Web應用程序
我正在創建一個應用程序，該應用程序將被其他應用程序（mobile/web）用於獲取數據。現在我有2個選項：
Web服務看起來更復雜，其中的任何客戶端將提供一個指定的格式（SOAP/REST）的數據和我的應用程序將解析請求，並返回由客戶要求的數據。數據如何被使用不是我的應用程序的問題。
我的問題是，通過一個簡單的Web應用程序接受XML格式的請求並用XML響應進行響應，可以實現相同的效果。直覺是，如果我們不確定誰將會使用這種服務，Web服務將會是更好的方式。但是，通過簡單的Web應用程序使用Web服務有什麼特別的優勢嗎？
在低級別的Web應用程序和Web服務是有點相同的事情。它們都通過http（s）進行操作。 SOAP只是一個明確定義的XML版本。 REST只是HTTP。如果你願意，你可以使Web應用程序看起來像Web服務，反之亦然。
主要區別是基於您使用的平臺的內部開發選項。例如，如果您使用的是Visual Studio，那麼添加WCF服務應用程序將爲您提供默認情況下針對WCF的項目。但選擇任何其他應用程序類型不會阻止您添加Web服務。
使用SOAP通常比普通的舊XML這些原因一個更好的選擇：
你的用戶會被期待它，並有可能知道如何已經閱讀。
您的用戶的開發環境可能會了解所有關於SOAP的知識，並能夠解讀它。 （如果您提供WSDL文件，那麼許多用戶將能夠在幾秒鐘內使用腳本生成您的類。）
您的消息更可能被很好地定義。我正在開發一個項目，此時對方已經定義了自己的隨機XML結構，這是一個噩夢。我從來不知道該期待什麼，而且他們的不同消息類型之間幾乎沒有一致性。至少如果他們已經同意遵守SOAP，那麼我可能會更容易解釋他們的消息。
如果您的應用程序不需要用戶界面，則將其設置爲Web服務。如果需要用戶界面，則使用Web應用程序。
這很簡單嗎？我不能簡單地創建一個返回XML作爲輸出的Web應用程序（就像我們在大多數AJAX應用程序中那樣）。爲什麼我需要Web服務？ – Kamal 2012-02-02 15:18:47
你不需要「它」。你當然可以按照你的建議來做 - 我建議基於ASP.NET MVC應用程序來做，如果它很簡單。 Web服務（WCF服務）使您可以靈活地使用相同的代碼工作，以便將服務展示給許多客戶端，而且功能強大。除此之外，Java或.NET中的SOAP客戶端不必操縱XML。對於這個問題，使用WCF，你的服務不需要接觸XML-- WCF將爲你做到這一點。 – 2012-02-02 15:52:01
我的問題是，通過一個簡單的網絡應用程序可以實現同樣的效果，該應用程序接受 XML格式的請求並用XML響應進行響應。
這是一個web服務。我認爲這是一個術語問題。除了使用Web服務之外，您無法解決這個問題，無論它是基於平穩還是基於SOAP，但是如果您以XML格式將數據傳遞給客戶端，則響應XML請求，這是一項Web服務。
我懷疑你的意思是要問你是否應該使用RESTful Web服務或基於SOAP的複雜方法。對我來說，答案取決於你的'服務'需要多少功能。
SOAP
如果你的服務有很多的功能比Java和/或Visual Studio的用戶寧願導入您的WSDL文件，並與所有爲他們做的XML解析使用你的服務作爲一個對象，所以SOAP將是答案。
REST
如果你只有幾個功能，具有非常基本的輸入參數和響應數據，然後SOAP可能是矯枉過正。
MySite.com/Add/5/3
或
MySite.com/GetStockSymbol/Facebook
或
MySite.com/GetWeather/Paris/France
如果我們想的術語，我認爲這是主要的問題在這裏。
Web服務是指通過某種Web界面以任何格式（XML/JSON等）提供數據的軟件。該接口可以稱爲API（應用程序編程接口）。 REST和SOAP是設計API的方式。
應用程序是使用Web服務提供的API的軟件。
換句話說，Web服務是「服務器」，應用程序是「客戶端」。通常服務器提供服務的機器和客戶端服務用戶因此，無論您選擇如何構建您的系統，我都會將提供數據的部分稱爲「Web服務」，並將數據作爲「應用程序」（或「Web應用程序」）使用。
聽起來就像你的情況，你正在構建一個Web服務，爲多個應用程序提供XML格式的數據。所以我的答案是：建立你已經建立的東西，並稱之爲網絡服務。
因此，如果我們正在建設一個網站，我們是否總是需要（至少）兩臺機器/服務器？一個用於從用戶界面（典型MVC）和另一個REST服務（其他地方部署）訪問前者（MVC的控制器）的用戶請求？ – user7 2018-02-17 07:22:14
不知道我是否理解了這個問題，但是你是否總是需要至少2臺服務器來構建一個網站，當然不是。網站通常只有一臺爲瀏覽器提供HTML的服務器。或者你也可以只有一臺服務器，例如服務器JSON通過例如REST API。 – Jeewes 2018-02-17 12:18:22
如果單個服務器返回HTML（視圖），那麼數據檢索邏輯也是MVC控制器的一部分嗎？如果我不希望那樣（不想在控制器中使用業務邏輯），那麼我必須有一個REST API端點才能獲得它。在這種情況下，控制器必須擊中該API。我對嗎？ – user7 2018-02-17 13:11:07
我知道爲時已晚重播，但我仍然希望
Web服務的方法是很好的，如果
一個。僅與Web服務進行企業集成，如集成分佈式模塊/應用程序。
b。適用於分佈式應用程序
c。不止一個消費者提供相同的服務 - 像銀行從信用報告機構消費數據
d。消費者需要不同格式的數據 - 就像一個消費者（客戶）想要的XML格式一樣，另外一個會在JASON ..等
我想這可能會幫助你解決你的困惑
有WEB的兩個主要用例是在行業
摘自我問這個問題超過3張贊成票回來，從那時起了很多的水已經從橋下流過。我從事過數十種Web應用程序並創建了數百種Web服務。所以我想在這裏回答我自己的問題是有道理的。
我面臨當我問這些問題的關鍵是，我得到了條款的應用和服務之間的困惑（注意，網絡是在Web應用和Web服務的共同元素）。正如名字所暗示的那樣，應用程序本身就是一種應用程序，而服務則是爲了服務其他人。除非有人打算使用它，否則服務可能沒有意義。它可以服務於一個或多個應用程序或服務。
現在，如果我看我的問題
我創建將由其他應用程序 （移動/網絡）用於獲取數據的應用程序。現在我有2個選項，1.創建我的 應用程序作爲簡單的Web應用程序2.創建Web服務。
我想告訴自己：「老兄！如果有一個實體接受請求並返回數據，那麼您正在談論一項服務。」因爲我不擔心這些數據會發生什麼？誰會使用它？這將如何顯示？
我正在請求並返回數據。現在我怎麼做是實施的一部分。我可能會使用SOAP或REST。我可能會使用Jersey或Spring MVC/REST，或者可能是一個簡單的servlet，它接受請求並以JSON或XML或String或任何其他所需格式返回數據。
Web服務不總是有一個UI。它們通常API的使用JSON，也可以使用SOAP和XML主要SOA類型，也可以是插座，以及服務器和其他科技Web服務等。
Web應用程序可以放在一起許多方面。有多種方式通過編排多個Web服務來創建您的應用程序，並通過單獨的gui來控制與這些服務相關的應用程序。另一種不使用服務的方式是將代碼程序化地嵌入到UI界面應用程序中，或者甚至更好地製作一個面向對象的應用程序，該應用程序稍後將自己的服務在模型中分離出來，控制器可以訪問該應用程序，並將其自己的視圖訪問後端服務的GUI，甚至更復雜的應用程序，這些應用程序通過某些GUI傳遞A2B，B2B，B2C服務。
服務並不總是有一個GUI，他們可以有一個CRUD來維護數據，但是一旦你開始擁有這些類型的功能，它就成爲一個獨立的應用程序。這些服務適用於比自己更重要的事情。這個應用程序創建你的應用它必須有一個目的。通常，需要多個盲人服務才能完成應用程序，並且存在某種界面。
如果你只是盲目地向你的服務發送一個uri請求，並且它盲目地發回json，那是一種服務。什麼是盲目發送這個？如果你，那麼不是一個應用程序。如果遇到某種問題，那麼它就成爲一個應用程序，這個問題就是一個訪問服務的GUI，整體來說，它是一個數據管理應用程序系統。現在，如果您在前面放置一個圖層以便以網站的形式展示這些數據，那麼您現在有一個產品可以顯示這些數據，一個用於管理它的產品，以及這些數據是真正的產品，並且可以通過Web服務訪問，它現在是一個完整的應用程序。你的努力創造這成爲你的應用程序。
從REST Web服務由Leonard Richardson和Sam Ruby中，ISBN：978-0-596-52926-0：
Web服務確實非常相似的Web應用程序，但資源創建是他們不同的地方之一。這裏的主要區別在於HTML表單目前僅支持GET和POST。這意味着Web應用程序必須使用重載POST來傳達任何不安全的操作。
保持簡單（因此，如果一個Web應用程序爲你工作，建立它;不是一個服務，但是這是我的看法）:) – 2012-02-02 11:11:16
我的觀點是，一個Web應用程序適用於大多數的條件下工作，那麼爲什麼要使用服務呢。 – Kamal 2012-02-02 11:15:39