为什么在内部项目中使用 ASP.Net Web Api 而不是 SignalR答案

【问题标题】：Why use ASP.Net Web Api instead SignalR for internal project为什么在内部项目中使用 ASP.Net Web Api 而不是 SignalR
【发布时间】：2014-08-25 06:59:17
【问题描述】：

我知道，ASP.NET Web API 是为创建 restful APIS 而设计的，而 SignalR 是为实时通信而设计的。所以它们不是相互竞争的技术。

想象一下：您正在创建一个客户端/服务器应用程序，您正在编写一个桌面客户端，它将连接到服务器以运行一些操作。操作由客户端启动，而不是由服务器启动，因此它们都可以工作。

如果这是一个内部应用程序，并且您没有公开 API，为什么要使用 Asp.Net Web Api 而不是 SignalR？

在这两种方法中，服务器中的方法都会在客户端调用它们时运行。在 Web Api 中作为控制器中的操作，在集线器中的信号 R 中。两者都允许您向方法发送参数，并在客户端获取结果。

知道 SignalR 中的流量比 Web Api 中的流量要低一点（因为在 websocket 中，HTTP 连接是永久建立的，而不是为每个请求创建的），我会选择 SignalR。我错过了什么吗？

【问题讨论】：

关于 SignalR 的较低流量，只是指出默认情况下 SignalR 每 10 秒通过连接发送保持活动消息，所以我不确定这是否是 SignalR 的好标准.
在对这个问题给出的所有答案中，我会说你选择了最没用的一个作为接受的答案

标签： c# asp.net-mvc asp.net-web-api websocket signalr

【解决方案1】：

为什么不两者兼而有之？

您可以使用 WebAPI 来提供批量数据，而 SignalR 作为可选的东西来提供数据的更新。因此，您将提供两种功能，首先是允许第三方消费者使用的 REST，并且还提供像 SignalR 或直接 WebSockets 这样的推送技术，以允许调用者订阅特定数据集的更改。

请记住，SignalR 不仅仅是 WebSockets，事实上，您需要 Windows 8 或 Windows 2012 作为服务器才能使用它们。否则，它将回退到另一个可能没有你想象的那么好用的传输。此外，正如 Daniel 指出的那样，SignalR 的可扩展性是......善良或有限的，甚至他们自己的文档也指出您不应该将它用于实时场景或非常分段的数据。 SignalR 仅用于一般广播，如果您使用的是 Windows 8/2012 或第三方组件，我更喜欢使用本机 Windows API 直接使用 WebSockets。

如果客户端始终是动作发起者，并且请求的频率不规则或不高，那么可能 REST 请求/响应方法简化了很多事情。如果不是这样，客户端会非常频繁地请求和/或以恒定速率进行请求，那么请使用 WebSocket，但您需要多做一些工作。

【讨论】：

【解决方案2】：

SignalR 在大多数情况下对于请求/响应来说都是多余的，我会选择 REST。然后使用 SignalR 进行推送更新。

对于推送更新，您可以使用此库抽象 SignalR（我是作者） https://github.com/AndersMalmgren/SignalR.EventAggregatorProxy

【讨论】：

【解决方案3】：

在利弊中，您应该添加每个解决方案的限制和可扩展性。我不记得这些数字，但 SigalR 需要大量资源来维持连接，尤其是与旧浏览器 (5000 clients is the default limitation on IIS) 的连接。而使用 WebApi，您关注的是您将有多少请求，而不是将连接多少客户端（即使他们什么都不做）。

WebApi 也更容易横向扩展。使用 SignalR，您必须设置可能成为瓶颈的 backplane。

在 SignalR 中，如果您映射 users and the connection，如果您计划添加更多服务器，最好选择适合未来需求的解决方案。

【讨论】：

【解决方案4】：

来自SignalR's official page：

ASP.NET SignalR 是一个供 ASP.NET 开发人员使用的库，它简化了向应用程序添加实时 Web 功能的过程。实时网络功能是让服务器代码在可用时立即推送内容到连接的客户端的能力，而不是让服务器等待客户端请求新数据 .

按照您描述问题的方式，您不需要这些功能。鉴于 SignalR，为了提供这些功能，会让您失去一些有用的 HTTP 特性（缓存、内容协商等），您可以利用这些特性来解决您的问题，我会选择 WebAPI。

【讨论】：

【解决方案5】：

使用 SignalR，您可以使用从服务器到客户端/客户端的推送。这类似于 WCF 双工，但更简单的实现方法是 SignalR，而不是 WCF 双工。 WebAPI 没有来自服务器端的 WCF 双工或信号推送响应。这是同时使用 WebAPI 和 SignalR 的第一个原因。

第二个原因与 SignalR 在服务器和客户端之间的三种不同类型的连接隧道有关。 SignalR首先尝试套接字，然后是第一个协议失败尝试第二个，如果第二个失败尝试服务器和客户端之间的第三种协议通信。

第三个原因是使用 WebAPI 需要调用数据来接收。使用 SignalR，您可以向服务器发送请求，服务器可能会在数据可用时做出响应。不需要每次都发送请求来检查。

WebAPI 和 SignalR - 将其用于与您想要实现的目标相关的特定案例。与 WebAPI 相比，您需要了解 SignalR 具有更复杂的循环工作流程。

【讨论】：

【解决方案6】：

使用像 web api 这样的框架最令人信服的理由是方便。一个优点是基于请求标头的内容协商。如果您要求 json，它会自动返回 json。与 xml 或其他标准格式相同。它还具有出色的格式化程序系统，使您能够支持自定义需求。它的配置也很简单，易于设置。

您完全可以创建自己的框架，甚至使用 MVC、WebForms 或任何其他方式来公开 Web 端点，但您通常会在响应中硬编码格式（json、xml、html 等）

无论如何，归根结底，您只需要一些能够说明 http - 请求 -> 响应的东西。

【讨论】：