为什么要使用ASP ?. Net Web Api代替SignalR用于内部项目
本文关键字：代替 Api SignalR 用于 项目 内部 Web Net ASP 为什么 | 更新日期: 2023-09-27 18:11:18
我知道，ASP。. NET Web API是为创建restful API而设计的，而SignalR是用于实时通信的。所以它们不是相互竞争的技术。
想象一下:你正在创建一个客户端/服务器应用程序，你正在编写一个桌面客户端，它将连接到服务器来运行一些操作。操作是由客户端启动的，而不是由服务器启动的，所以它们都可以工作。
如果这是一个内部应用程序，而你没有公开API，为什么要使用Asp。. Net Web Api代替SignalR?
在这两种情况下，服务器中都有方法，当客户端调用它们时，这些方法将运行。在Web Api中作为控制器中的动作，在hub中的信号R中。两者都允许您向方法发送参数，并在客户机中获取结果。
知道SignalR中的流量比Web Api稍低(因为在websocket中HTTP连接是永久建立的，而不是为每个请求创建)，我会选择SignalR。我错过什么了吗?
为什么不同时使用呢?
你可以使用WebAPI来提供批量数据，而SignalR作为一个可选的东西来提供数据更新。因此，您将提供这两种功能，首先是REST允许第三方消费者，然后还提供像SignalR这样的推送技术，或者直接提供WebSockets，以允许调用者订阅特定数据集的更改。
请记住SignalR不仅仅是WebSockets，如果事实上，你需要Windows 8或Windows 2012作为服务器才能使用它们。否则，它将退回到另一个可能不像您想象的那样工作的传输。此外，正如Daniel指出的，SignalR的可扩展性是……种类或限制，甚至他们自己的文档都说明您不应该将其用于实时场景或非常分段的数据。SignalR只是用于一般广播，如果你使用的是Windows 8/2012或第三方组件，我更喜欢直接使用自带Windows API的WebSockets。
如果客户端始终是动作发起者，并且请求的频率不规律或不高，那么REST请求/响应方法可能会大大简化事情。如果不这样，客户端经常和/或以恒定的速率进行请求，那么使用WebSocket，但您将需要更多的工作。
SignalR在大多数情况下对于请求/响应来说是多余的，我将使用REST。然后使用SignalR来推送更新。
对于推送更新，你可以用这个库抽象SignalR(我是作者)https://github.com/AndersMalmgren/SignalR.EventAggregatorProxy
在利弊中，您应该添加每个解决方案的限制和可伸缩性。我不记得具体数字了，但是SigalR需要大量资源来维护连接，特别是在旧浏览器上(5000个客户端是IIS的默认限制)。而使用WebApi，你关注的是你将有多少请求，而不是有多少客户端将被连接(即使他们什么都不做)。
WebApi也更容易扩展。使用SignalR，您将不得不设置一个可能成为瓶颈的背板。在SignalR中，如果您映射用户和连接，如果您计划添加更多服务器，则最好选择适合未来需求的解决方案。
来自SignalR的官方页面:
ASP。. NET SignalR是一个面向asp.net的库。. NET开发人员简化了向应用程序添加实时 web功能的过程。实时web功能是让服务器代码在内容可用时立即将内容推送到连接的客户端，而不是让服务器等待客户端请求新的数据。
你描述问题的方式，你不需要那些特征。考虑到SignalR，为了提供这些特性，使您失去了一些有用的HTTP特性(缓存、内容协商等)，您可以利用这些特性来解决问题，我将使用WebAPI。
使用SignalR，您可以使用从服务器到客户端/客户端推送。这有点像WCF双工，但更简单的实现方法是SignalR而不是WCF双工。WebAPI没有来自服务器端的WCF双工或信号推送响应。这是同时使用WebAPI和SignalR的第一个原因。
第二个原因与SignalR有关，服务器和客户端之间的三种不同类型的连接隧道。SignalR首先尝试套接字，然后是第一个协议失败尝试第二个，如果第二个失败尝试第三种类型的协议通信服务器和客户端之间。
第三个原因是使用WebAPI需要调用数据来接收。使用SignalR，您可以向服务器发送请求，当数据可用时服务器可能会响应。不需要每次都发送请求来检查。
WebAPI和SignalR -将其用于与您想要实现的目标相关的特定情况。你需要了解SignalR与WebAPI相比有更复杂的周期工作流。
使用web api这样的框架最令人信服的原因是方便。一个优点是基于请求报头的内容协商。如果你请求json，它会自动返回json。与xml或其他标准格式相同。它也有一个伟大的格式化系统，使您能够支持自定义需求。它的配置也很轻，容易设置。
你可以很好地创建自己的框架，甚至使用MVC, WebForms或任何其他方式来暴露web端点，但你通常会在响应中硬编码格式(json, xml, html等)
无论如何，在一天结束的时候，你只需要一些东西来表达http - request -> response