我们在WCF服务中同时使用SOAP和REST端点。ASP.NET Web API对我们意味着什么？

在我们的服务上，我们配置了几个端点，允许我们将相同的接口发布到SOAP1.1和1.2客户端以及使用XML或JSON的HTTP客户端。现在WCF REST团队已经合并到ASP.NET团队中来创建Web API，这对我们将来意味着什么？是否仍然支持将WCF接口公开为XML/JSON服务？我们应该将REST端点移动到WebAPI框架吗？这是MS REST堆栈的最后一个班次吗？

好问题。我不为微软工作，也没有任何内部信息，但我的理解是，WCF将能够永远公开XML和JSON。事实上，如果您只是公开JSON或XML端点，那么您就没有进行REST。真正的问题是，您是将HTTP谓词（DELETE、PUT、POST、GET）作为API的一部分使用，还是仅仅公开与SOAP方法等效的方法。如果您正在使用HTTP谓词，那么将其余部分迁移到WebAPI可能是一个很好的长期策略。如果您不是，那么您可以愉快地使用WCF（继续告诉您的客户，您使用REST是出于营销原因，对营销人员来说，这只是一个流行语）

---

如果您使用的是HTTP谓词，那么同时使用WCF和WebAPI并不难。您所需要做的就是从服务本身删除所有逻辑，并将其作为业务层方法公开。然后，服务的两个子级都可以使用这些方法，以适当的方式调用它们并形成结果。

要回答这个问题，您需要了解一些ASP.NET Web API的历史

最初是ASP.NET Web API，它是WCF Web API，是Codeplex上的一个项目，它扩展了WCF，使其更容易支持REST样式的服务。WCF完全建立在SOAP作为其核心消息传递类型的基础上，因此将HTTP用作传输层协议以外的任何协议都需要一种不同的方法，具有不同的属性集，并且通常与框架的其余部分不匹配

WCF Web API以支持HTTP作为应用程序级传输机制所需的所有方式扩展了WCF框架。它引入了基于资源URI的请求路由、根据

Accept

头的动态格式以及之前WCF中缺少的其他内容

然而，在其开发过程中，很明显这些技术已经存在于.NET中的MVC堆栈中。因此，他们决定将工作移交给ASP.NET MVC团队，而不是拥有两套相互竞争的技术，ASP.NET Web API由此诞生

---

如果您正在执行REST样式的服务，那么ASP.NET Web API比WCF框架更适合您的需要。WCF团队不会进一步支持REST风格的体系结构；WCF框架的这些特性有效地被Web API所包含，在这里它找到了更自然的契合点

---

您是否应该重新编写服务以使用新的Web API？嗯，WCF的其他功能不会突然停止工作。你应该只考虑移动，如果它给你一些你所追求的特征（比如动态内容格式选择），或者如果你想不断地开发你的API（因为Web API比WCF更容易使用），你是完全正确的，我们所做的不是适当的，但是我不知道正确的术语。“将我们的服务公开为XML和JSON”。我们不使用DELETE和PUT，因此我们可能没有太多的理由进行转换。除非您想进行实际rest，否则您不仅没有理由迁移，而且很难迁移到WebAPI。如果您想进行实际rest，那么根据定义，您的端点将不同（也就是说，您需要有两个方法的实现，一个用于SOAP，一个用于REST）对于我的问题，我得到了两个很好的答案。这两个答案都说明了实现“真正”REST接口的新框架的优越性，都意味着在新的平台上不可能支持SOAP接口。我接受了Stigar的答案，因为它对我的具体情况更有用。