Web 服务与 Web 应用程序

Posted 2023-02-23

【中文标题】Web 服务与 Web 应用程序

【英文标题】：Web Service vs Web Application

【发布时间】：2012-02-25 01:02:27

【问题描述】：

我知道这是一个老问题，肯定已经回答了一百次了，但我还没有找到满意的答案。

我正在创建一个应用程序，其他应用程序（移动/网络）将使用它来获取数据。现在我有两个选择：

将我的应用程序创建为一个简单的 Web 应用程序。 创建网络服务。

Web 服务看起来更加复杂，其中任何客户端都将以指定格式 (SOAP/REST) 提供数据，而我的应用程序将解析请求并返回客户端请求的数据。如何使用数据不是我的应用程序的问题。

我的问题是，同样可以通过一个简单的 Web 应用程序接受 XML 格式的请求并以 XML 响应进行响应来实现。直觉是，在我们不确定谁会使用这种服务的情况下，Web 服务将是一种更好的方式。但是，与简单的网络应用程序相比，使用网络服务有什么特别的优势吗？

【问题讨论】：

保持简单（因此，如果 WebApp 适合您，请构建它；而不是服务。但这是我的看法）:)

我的意思是，Web 应用程序适用于大多数情况，那为什么还要使用服务呢。

【参考方案1】：

在底层，Web 应用程序和 Web 服务是一回事。它们都通过 http(s) 运行。 SOAP 只是一个定义良好的 XML 版本。 REST 有点像 HTTP。如果您愿意，您可以使 Web 应用程序看起来像 Web 服务，反之亦然。

主要区别在于基于您使用的平台的内部开发选项。例如，如果您使用的是 Visual Studio，那么添加 WCF 服务应用程序将为您提供一个默认面向 WCF 的项目。但选择任何其他应用程序类型不会阻止您添加 Web 服务。

由于以下原因，使用 SOAP 通常比普通的旧 xml 更好：

您的用户会期待它，并且可能已经知道如何阅读它。

您的用户的开发环境可能对 SOAP 了如指掌，并且能够开箱即用地解释它。 （如果您提供 WSDL 文件，那么许多用户将能够使用脚本在几秒钟内生成您的类。）

您的消息更有可能被明确定义。我正在做一个项目，对方已经定义了他们自己的随机 XML 结构，这是一场噩梦。我真的不知道会发生什么，而且它们不同的消息类型之间几乎没有一致性。至少如果他们同意遵守 SOAP，那么我可能会更轻松地解释他们的消息。

【参考方案2】：

如果您的应用程序不需要用户界面，则将其设为 Web 服务。如果需要用户界面，请使用 Web 应用程序。

【讨论】：

就这么简单吗？我不能简单地创建一个返回 XML 作为输出的 Web 应用程序（就像我们在大多数 AJAX 应用程序中所做的那样）。为什么需要网络服务？

你“不需要”它。你当然可以按照你的建议去做——如果它那么简单，我建议你基于一个 ASP.NET MVC 应用程序来做。 Web 服务（WCF 服务）使您可以灵活地使用相同的代码工作以将服务公开给许多客户端，并且功能强大。除此之外，Java 或 .NET 中的 SOAP 客户端不必操作 XML。就此而言，使用 WCF，您的服务也不需要接触 XML - WCF 将为您完成。

所以你是说如果数据来自其他服务器你不需要应用程序（客户端或浏览器端）？我猜对了吗？

@muneeb：我的意思是，如果没有人会与应用程序交互，那么就让它成为一个 Web 服务。然后相同的功能将可用于不同的 Web 应用程序（通过 javascript）、ETL 流程或其他 Web 服务。

【参考方案3】：

我的问题是同样可以通过一个简单的网络应用程序来实现 XML 格式的请求并以 XML 响应进行响应。

这是一个网络服务。我认为这是一个术语问题。除了使用 Web 服务之外，您没有其他方法可以解决这个问题，它是基于 SOAP 还是基于 SOAP 取决于您，但是如果您以 XML 格式将数据传递给客户端，以响应 XML 请求，那就是 Web 服务。

我怀疑您的意思是您是否应该使用 RESTful Web 服务或复杂的基于 SOAP 的方法。对我来说，答案取决于您的“服务”中需要多少功能。

SOAP

如果您的服务比 java 和/或 Visual Studio 的用户更愿意导入您的 WSDL 文件并将您的服务用作对象，并为它们完成所有 XML 解析，那么 SOAP 将是答案。

休息

如果您只有几个函数，具有非常基本的输入参数和响应数据，那么 SOAP 可能会过大。

MySite.com/Add/5/3

或

MySite.com/GetStockSymbol/Facebook

或

MySite.com/GetWeather/Paris/France

【参考方案4】：

如果我们认为术语，我认为这是这里的主要问题。

Web 服务是指通过某种 Web 界面以任何格式（XML/JSON 等）提供数据的软件。该接口可以称为API（应用程序编程接口）。 REST 和 SOAP 是设计 API 的方法。

应用程序是使用 Web 服务提供的此 API 的软件。

换句话说，Web 服务是“服务器”，而应用程序是“客户端”。通常服务器为机器服务，客户端为用户服务。

因此，无论您选择以何种方式构建系统，我都会将提供数据的部分称为“Web 服务”，将使用数据的部分称为“应用程序”（或“Web 应用程序”，如果有的话）。

听起来，在您的情况下，您正在构建一个为多个应用程序提供 XML 格式数据的 Web 服务。所以我的答案是：构建你已经在构建的东西并将其命名为 web 服务。

【讨论】：

那么，如果我们正在构建一个网站，我们是否总是需要（至少）两台机器/服务器？一个用于从 UI（典型的 MVC）获取用户请求，另一个 REST 服务（部署在其他地方）由前者（MVC 的控制器）访问？

不确定我是否完全理解了这个问题，但是您是否总是需要至少 2 台服务器来构建网站，绝对不是。网站通常只有一台服务器为浏览器提供 html。或者您也可以只有一台服务器来服务，例如JSON 通过例如 REST API。

如果单个服务器返回 HTML（视图），那么数据检索逻辑是否也是 MVC 控制器的一部分？如果我不希望它存在（不希望控制器中有业务逻辑），那么我必须有一个 REST API 端点来获取它。在这种情况下，控制器必须命中该 API。我说的对吗？

Or you can also have just one server that serves e.g. JSON via e.g REST API -> 它不能在 HTML 中呈现。所以 MVC 控制器必须使用它并将模型传递给视图。同样，这里涉及到两件事吗？

【参考方案5】：

我知道重播为时已晚，但我仍然想要

如果

，Web 服务方法很好

一个。仅与 Web 服务的企业集成，例如集成分布式模块/应用程序。

b.适用于分布式应用程序

c。同一服务的多个消费者 - 就像银行消费来自信用报告机构的数据

d。消费者需要不同格式的数据 - 就像一个消费者（客户）想要的 XML 格式，其他的会是 JASON ..etc

【参考方案6】：

我认为这可能会帮助您解决您的困惑

业界主要有两种WEB用例

企业对消费者（B2C）：只要有消费者直接 与业务进行交互以满足其需求，我们总是使用 用于在两方之间提供通信的 Web 应用程序。 Business to Business(B2B) : 表示业务需求的一部分 来自业务另一部分的一些输入/服务。总是一个 Web-Service 用于满足企业对企业的需求。 通常消费者从不直接与我们的 Web 服务交互 仅与 Web-Application 交互和 Web-Application 交互 带有用于信息/数据或处理的网络服务。

取自http://coder2design.com/java-interview-questions/

【参考方案7】：

我在 3 多年前问过这个问题，从那时起，桥下流了很多水。我从事过数十个 Web 应用程序并创建了数百个 Web 服务。所以我想在这里回答我自己的问题是有意义的。

当我问这个问题时，我面临的挑战是我对应用程序和服务这两个术语感到困惑（请注意，Web 是 Web 应用程序和 Web 服务中的常见元素）。顾名思义，应用程序本身就是一个应用程序，而服务是为他人服务的。一项服务可能没有任何意义，除非有人要使用它。它可以为一个或多个应用程序或服务提供服务。

现在如果我看看我的问题

我正在创建一个将被其他应用程序使用的应用程序 （移动/网络）来获取数据。现在我有 2 个选项，1. 创建我的 应用程序作为一个简单的 Web 应用程序 2. 创建一个 Web 服务。

我想告诉自己“老兄！如果有一个实体接受请求并返回数据，那么你说的是服务。”因为我不担心这些数据会发生什么？谁会使用它？那将如何显示？

我正在接受请求并返回数据。现在我如何做到这一点是实施的一部分。我可能会使用 SOAP 或 REST。我可能使用 Jersey 或 Spring MVC/REST，或者可能是一个简单的 servlet，它接受请求并以 JSON 或 XML 或字符串或任何其他所需格式返回数据。

【参考方案8】：

Web 服务并不总是有 UI。它们通常是使用 JSON 的 API，也可以是主要使用 SOAP 和 XML 的 SOA 类型，也可以是套接字、服务器和其他微 Web 服务等。

Web 应用程序可以通过多种方式组合在一起。有几种方法可以通过多个 Web 服务的编排来创建您的应用程序，以及一个单独的 gui 来控制与这些服务相关联的它们。不使用服务的另一种方法是将代码嵌入到您的 UI 界面应用程序中，或者甚至更好的是，制作一个面向对象的应用程序，该应用程序稍后在模型中分离出自己的服务，控制器可以访问这些服务，并拥有自己的视图：访问后端服务的 GUI，或者更复杂的应用程序，从某个 GUI 传递 A2B、B2B、B2C 服务。

服务并不总是有一个 GUI，它们可以有一个 CRUD 来维护数据，但是一旦你开始拥有这些类型的功能，它就会成为一个独立的应用程序。这些服务适用于比它们本身更大的东西。此应用程序创建您的应用程序。它必须有一个目的。一般情况下，完成你的申请需要不止一个盲注服务，并且有某种接口。

如果你只是盲目地向你的服务发送一个uri请求，而它又盲目地发送回json，那就是一个服务。这是什么盲送？如果你，那么不是一个应用程序。如果是某种 crud，那么它就变成了一个应用程序，crud 是一个用于访问服务的 GUI，并且作为一个整体，它是一个数据管理应用程序系统。现在，如果您在前面放置一层以网站方式展示这些数据，那么您现在有一个产品来显示这些数据，一个产品来管理它，以及真正的产品数据，并且可以通过 Web 服务访问，它现在是一个完整的应用程序。您创建它的努力将成为您的应用程序。

【参考方案9】：

来自 Leonard Richardson 和 Sam Ruby 的 RESTful Web 服务，ISBN：978-0-596-52926-0：

Web 服务确实与 Web 应用程序非常相似，但资源创建是它们不同的地方之一。这里的主要区别是 HTML 表单目前仅支持 GET 和 POST。这意味着 Web 应用程序必须使用重载的 POST 来传达任何不安全的操作。

【参考方案10】：

我猜 Web 应用程序与 Web 服务的区别在于部署因素比率不同，这意味着 Web 应用程序的部署（本地）将受限于 Web 服务（全球）的情况。 另外，当我们想到 UI 视角时，更好的选择是 Web 应用程序，但当我们想到编程和数据传输视角时，主要选择 Web 服务。 Web 应用程序需要使用带有 Spring mvc 等框架的 servlet。另一方面，如果您想将相同的应用程序部署到多个平台，请通过 Rest/Soap 实现将其作为 Web 服务，这样 Web 应用程序的行为就会更改为服务。

总之，

   WebService   =

                 (RestApi/Soap)    # added 
             /         |         \
(client1)---(Web Application)---(clientN)

【参考方案11】：

这是了解它的简单方法：

Web 应用程序 表示人类可以阅读。 它是通过浏览器访问的。

而

Web Services 是指计算机可以读取。 它可以从任何语言或平台访问。

例如：

Yatra.com（基于 Java 的服务）应用程序通信 Paypal.com（基于 Python 的服务）应用程序