Ric*_*olo 9 c# asp.net-mvc websocket signalr asp.net-web-api
我知道,ASP.NET Web API旨在创建宁静的APIS,而SignalR则用于实时通信.所以他们不是竞争技术.
想象一下:您正在创建一个客户端/服务器应用程序,您正在编写一个桌面客户端,该客户端将连接到服务器以运行某些操作.操作由客户端启动,而不是由服务器启动,因此它们都可以工作.
如果这是一个内部应用程序,并且您没有暴露API,为什么要使用Asp.Net Web Api而不是SignalR？
在这两种方法中,服务器中的方法将在客户端调用它们时运行.在Web Api中作为控制器中的动作,在集线器中的信号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
使用像 Web API 这样的框架最令人信服的原因是方便。优点之一是基于请求标头的内容协商。如果你请求 json，它会自动返回你的 json。与 xml 或其他标准格式相同。它还具有出色的格式化系统，使您能够支持自定义需求。它的配置也很简单并且易于设置。
您完全可以创建自己的框架，甚至使用 MVC、WebForms 或任何其他方式来公开 Web 端点，但您通常会在响应中硬编码格式（json、xml、html 等）
不管怎样，最终你只需要一些能够以 http - 请求 -> 响应的方式表达的东西。