asp.net-mvc - Web Api - 架构

Question

在过去的几年里，我看到了许多 Web API 的兴起 - 通过纯 HTTP 而不是通过更正式的服务契约(如 SOAP 或 WS*)公开的服务。 Microsoft 刚刚推出了一个名为“ASP.NET Web API”的新框架，它可以轻松构建适用于广泛客户端的 HTTP 服务。如果我是 .net 粉丝，它是另一个通信框架(仅次于 asmx、wcf、ria 等)。现在，作为一名快乐的架构师，我必须对技术做出决定。

Asp.net Web Api真的是新架构的好选择吗？记住 Linq2Sql，我不想投资于“一次性”api。

WebBindings 在 WCF 中还有用吗？

Answer 1

就堆栈溢出问题而言，这个问题的问题在于它基本上是主观的。因此，我很确定它会关闭 - 但无论如何我都会坚持我的 2 便士(实际上更像是 2 英镑)，如果它关闭了那就这样吧。

首先，Linq2Sql 不是“一次性的”——它仍然存在，不会消失。它没有被开发 - 这完全是另一回事。

无论如何 - Asp.Net Web API 是 REST Web 服务支持的形式化，由来自同一团队的许多人在 Asp.Net MVC 上工作(编辑)，并使用非常相似的方法来实现可扩展性、流水线、横切关注点(例如身份验证、日志记录、验证)等。使用与否完全取决于您是否打算开发 RESTful Web 服务。如果您是，并且您使用的是 .Net 4+，那么，在我看来，如果您不这样做，那就太疯狂了。

Web API 的整体架构非常好，您可以毫不费力地扩展其中的大部分内容。特别是，他们处理内容协商的方式非常好，这使得支持 JSON 请求但仅因为客户端发送 Content-Type:application/json 就返回 XML 响应变得微不足道和 Accepts:application/xml。

作为一种服务器技术，它也非常非常快；部分原因是它完全是异步的(增加了可扩展性)，但也因为传入请求与被调用代码之间的堆栈非常浅。

不仅如此，您还可以在 IIS 和任何 .Net 应用程序中托管它 - 这增加了您的托管选项，同时也使它成为公共(public)网络(即非 Internet)环境中的网络内通信的候选者。

但是，如果您想编写 SOAP 或 WS-HTTP 服务，那么，不，Web API 不适合您 - 您会坚持使用 WCF。

简而言之，您需要将 Asp.Net Web API 纯粹视为在 .Net 上运行的服务器和客户端技术，而不是协议(protocol)或 Web 体系结构。它使您能够构建 RESTful Web 服务 - 您也可以在 MVC、WebForms(如果您真的想要)、.ashx 处理程序中或通过编写您自己的 HttpListener 来实现。

您选择哪一个完全由您决定。