为什么 WCF 用于 Intranet 服务？ [关闭]

Question

我正在处理一个新项目。 该项目的目的是集中所有服务调用并为其他服务提供单一入口点。

目前，开发人员调用大约 5 种不同的服务来从内部不同来源获取数据。

该项目将创建一个服务，公司的其他开发人员可以使用该服务从一个服务中调用所有这 5 种不同的服务。

我的问题是

我应该使用 Web API（RESTful）还是 WCF（基于 SOAP）构建服务？

我的经理建议我使用一种宁静的方式来创建此服务。但是，由于该服务在公司内部使用，我相信 WCF 将是更合适的方法，因为 WSDL，您可以使用它来创建代理类和使用对象，而不是客户端解析返回的数据。

此外，WCF 是操作驱动的，而 Web API 是资源驱动的。

什么时候使用动作驱动模型，什么时候使用资源驱动？

如果您能深入了解我的情况并帮助我决定将哪种方法应用于我的项目，我将不胜感激。

这是我目前所拥有的，但仍然不足以说服我使用其中一个。

WCF

1. 基于 SOAP 的服务
2. 多种传输协议（HTTP、TCP、UDP 等）
3. 用于创建代理的 WSDL（生成类型安全的绑定器类/对象）
4. 它允许客户端像类库一样引用服务端点，这意味着您无需在桌面客户端中处理 XML 或 JSON。您正在使用类和对象。
5. 与 Web API 相比，开销更大
6. 内部/内部网
7. 动作驱动模型，重点关注服务能够执行的操作
8. WCFExtras+ 用于文档服务

网络 API

1. RESTful 服务
2. 基于 HTTP（一等公民）
3. 多种媒体类型（XML、JSON）
4. 重量轻
5. 没有 WSDL（通常客户端最终自己解析数据）
6. 公共 API（各种客户端）
7. 基于对象而非函数公开端点的资源驱动架构
8. 客户端互操作性
9. 使用 Swagger 的 ASP.NET Web API 帮助页面

更新：

我的问题是理解为什么应将 WCF 用于 Intranet 应用程序。是因为 WSDL 会自动为你创建代理类和 web api，你必须在客户端做更多的工作来解析返回的 xml 或 json？

Answer 1

要考虑的一个因素是现有服务代码是否“内置”到现有服务中。几年来，当我创建一个新服务时，所有代码都是 WCF 服务应用程序的一部分。这似乎是权宜之计，但却是短视的。

如果将应用程序组件构建到它们自己的库中会更好，然后可以通过 WCF 服务或 Web API 公开。如果它是这样构建的，那么做一个、另一个、改变主意或两者都做会容易得多。

我倾向于使用 Web API，因为 1) 任何客户端都更容易使用它，并且 2) 现在每个人似乎都专注于 Web API，这是一个积累经验的好领域。

对于内部使用的 API，我有一种方法可以为我提供与 WCF 服务相同的一些好处。

• “服务”是独立于 API 的库。它只是一个类库，我可以独立于 API 进行测试。
• 我在一个单独的库中为 API 及其模型创建了一个接口
• 我需要创建自己的客户端代码来测试 API，因此我创建了一个实现服务接口的可重用 HTTP 客户端。其他开发人员不需要使用它，但如果他们愿意，他们可以添加该接口和我现有的客户端。这样，他们无需编写和测试自己的客户端代码，而是已经完成并测试了一些东西。它们还有一个单独的接口和实现，便于依赖注入。
• 这可能有点矫枉过正，但我​​让我的 API 实现了相同的服务接口。这样，如果我在开发过程中修改接口（不是谈论对已发布接口的重大更改），很容易看出我需要在哪里更新 API、客户端等。

这为与内部客户合作提供了一些便利。缺点是它可能与开发 RESTful API 的最佳实践“脱节”。

IMO 最重要的是逻辑与 API 或 WCF 之间的功能分离。如果您以一种方式构建 API，然后想做一些不同的事情，那么您可以专注于它的那一端，而无需重写或重新测试代码中更重要的部分。