为什么使用ASP.Net Web Api代替SignalR进行内部项目

Question

我知道，ASP.NET Web API旨在创建宁静的APIS，而SignalR则用于实时通信。所以他们不是竞争技术。

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

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

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

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

Answer 1

为什么不两者？

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

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

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

Answer 2

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

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

Answer 3

在优点和缺点中，您应该添加每个解决方案的限制和可扩展性。 我不记得这些数字，但SigalR需要很多资源来维持连接，特别是旧浏览器（5000 clients is the default limitation on IIS）。 而使用WebApi，您可以专注于您将拥有多少请求，而不是将连接多少客户端（即使它们什么都不做）。

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

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

Answer 4

来自SignalR's official page：

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

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

Answer 5

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

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

无论如何，在一天结束时，你只需要一些会说出http - request - ＆gt;的内容。响应。

Answer 6

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

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

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

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