C# 为什么WCF用于内部网服务？

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

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

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

我的问题是

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

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

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

何时使用行动驱动模型，何时使用资源驱动模型

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

这是我到目前为止所拥有的，但仍然不足以说服我使用其中一种

周转基金

基于SOAP的服务

多传输协议（HTTP、TCP、UDP等）

用于创建代理的WSDL（生成类型安全绑定类/对象）

它允许客户端像类库一样引用服务端点，这意味着您没有在桌面客户端中处理XML或JSON。您正在使用类和对象

与Web API相比，具有更多的开销

内部/内部网

动作驱动模型，重点关注服务能够执行哪些动作

WCFExtras+用于文档服务

Web API

宁静服务

基于HTTP（一等公民）

多种媒体类型（XML、JSON）

轻量

没有WSDL（客户端通常会自行解析数据）

公共API（各种各样的客户端）

基于对象而非函数公开端点的资源驱动体系结构

客户端互操作性

使用Swagger的ASP.NET Web API帮助页

更新：

---

我的问题是理解为什么WCF应该用于intranet应用程序。这是因为WSDL为您自动创建代理类和Web API，您必须在客户端上做更多的工作来解析返回的XML或JSON？

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

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

我倾向于使用Web API，因为1）任何客户都更容易使用它，2）现在每个人似乎都在关注Web API，这是一个很好的体验构建领域

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

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

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

---

在我看来，关键在于逻辑和API或WCF之间的功能分离。如果您以一种方式构建API，然后想做一些不同的事情，那么您可以专注于这一点，而不必重写或重新测试代码中更重要的部分。

这可能会被认为“过于宽泛”，因为答案只会是意见。Web API更容易在不同的平台和工具集之间工作。当您可以为客户端和服务器使用完全相同的工具/库时，SOAP工作得最好。集成不同的工具，如gSOAP和微软的可能是一场噩梦。Web API甚至可以“手工”完成，根本没有专用的库，因为它归结为HTTP POST或GET。除了几次小小的呼叫之外，SOAP不可能用手工完成。我读到的所有文章都建议WCF应该用于内部网应用程序。然而，Web API应该用于公共API服务。我的问题是理解为什么WCF应该用于intranet应用程序。是因为WSDL自动为您创建代理类，还是因为web api，您必须在客户端做更多的工作来解析返回的xml或json？文章的意思可能是应该只用于intranet。即便如此，你需要支持iOS和Android手机和Mac，还是只支持Windows PC？只支持Windows PC