性能是不完全使用SignalR（网络套接字）来代替传统REST API的唯一原因吗？

我曾SignalR在多个项目中实现实时消息传递功能。它似乎工作可靠，并且非常易于学习使用。

至少对我来说，诱惑是放弃开发Web API服务，并将其SignalR用于一切。

我觉得这可以通过深思熟虑的设计来实现，如果可以的话，这意味着将需要更少的客户端代码。更重要的是，这将意味着将有一个单一的服务接口，而不是一个分离的接口，并且在最坏的情况下，可以将其连接起来而无需考虑何时渲染事物，等等。

因此，我想知道：

1. 除了性能之外，还有其他原因不使用SignalR代替所有Web服务吗？
2. SignalR的性能是否足以引起人们的注意？

能够将服务器端对象和服务定义转换为客户端服务访问代码而不用愚蠢的东西一直是我的梦想node.js。例如，如果我定义了一个有趣的对象InterestingObject以及该对象的服务，CRUD则InterestingObjectService可以定义到该服务的标准URL路由-例如“ / {serviceName} / {methodName}”，但是我仍然需要编写客户端代码才能访问服务。由于对象将被从客户端传递到服务器和背部，没有实际的原因有在客户端代码中显式定义对象，也无需显式定义执行CRUD操作的路由。我觉得应该有一种标准化所有方法的方法，这样就可以在假定服务访问从客户端到服务器再到服务器的工作透明的前提下编写客户端，就像我在编写WinForms或Java时一样Applet或Native App或您拥有的东西。

如果SignalR足以代替传统的Web服务使用，则它可能是实现此目的的可行方法。SignalR已经包含使集线器像我描述的服务那样工作的功能，因此我可以定义一个通用基础（CRUD）服务，该服务可以开箱即用地提供所有这些功能。然后，我几乎可以认为服务访问是理所当然的，这使我免去了重新编写代码以访问约定可以访问的内容的烦恼-更重要的是，我不得不花时间编写代码来定义如何对其进行更新。 DOM。

阅读我的编辑后，我觉得这可能有点荒谬，所以请随时问我是否对我的想法有疑问。基本上，我希望服务访问尽可能透明。

这两种技术的目的截然不同。

• REST用于对API的常规调用，而客户端是交换的活跃参与者。当客户端需要查找地址的GPS坐标时，客户端会启动对API的调用，并等待直到接收到坐标，或者发生错误，或者超时。

• Web套接字适用于所有需要以相反方式进行操作的事物。例如，当我使用Intranet网站实时向我显示日志和不同服务器的性能时，客户端可能是被动的，直到服务器向他发送新发布的日志消息或性能指标为止。

区别很明显：在第一种情况下，客户决定何时需要特定信息。在第二种情况下，客户端只是等待联系，可能不知道什么时候会联系。

在某种程度上，两者都是可以互换的：您可以在不需要时实现Web套接字（即，客户端将通过Web套接字而不是REST调用来调用服务器），并且可以使用轮询或长轮询来代替Web套接字（鉴于Web套接字如此流行直到成功使用了多年）。

但是它们的互换性要付出代价：

• 当使用轮询或长轮询而不是Web套接字时，通常会浪费带宽。

• 当您使用Web套接字执行可通过Web api完成的操作时，您将打开所有活动客户端的所有连接，而这可能并不是您真正想要的。对于您希望同时最多拥有5个客户的小型网站，这不是问题。对于Amazon AWS之类的服务，从技术上很难解决。

不需要时不要使用网络套接字。要获取地址的GPS坐标，在打开Web套接字连接，进行呼叫，等待答案并关闭连接时，我一无所获：REST满足了我在这种情况下的需要。

• 如果您反复发现自己并经常通过对服务的REST调用检查信息，则这可能是您应该使用Web套接字的好兆头。同样，Stack Overflow通过使用Web套接字减少了带宽使用，因为它可以帮助人们避免花费时间在主页上按F5来查看是否有新消息。

• 如果您发现打开了Web套接字连接，请使用它们进行单个调用，然后关闭它们，或者如果您的连接保持打开状态，但是服务器仅在客户端的请求下向客户端发送一些消息，请切换到REST。

而且，Web套接字的支持仍然有限，并且并不总是易于实现。尽管SignalR使其易于实现，但这并不意味着您在其他语言/环境/环境中实现它不会遇到任何困难。借助REST，这很容易：它可能是curl电话或每种主流语言都提供的类似功能。使用网络套接字，您无法确定使用[在此处插入您尚不知道的语言名称]来使客户端花费多长时间。

我在.NET，Python和node.js的多个项目中使用了Web套接字。

• 在.NET中，这并不是太困难，但是，我仍然花了几天的时间来找出一些神秘的问题，例如，连接一旦打开就掉线了。（这是在SignalR之前；我从未尝试过SignalR）。我还在Web套接字模式下使用了WCF，这也不是没有问题的（但是我相信WCF 总是伴随着问题）。

• 在node.js中，这是可行的，但是我不得不切换两次库，直到找到一个有效的库。我相信我已经花了至少一个星期的时间来尝试制作网络套接字Hello World。

• 在Python中，我尝试了一次，花了两三天，然后放弃了。它从来没有奏效。

将此与REST进行比较：使用一种新的语言/框架可能遇到的唯一问题是知道如何发布文件或接收非常大的二进制响应。我记得花了几个小时寻找某些语言的解决方案。尽管如此，特殊情况下的几个小时与简单的Hello World的几天或几周相比是什么。

只是我的2美分...

我认为这与性能无关。这是关于标准的。REST是一种标准，恕我直言，它具有以下优点：

• HTTP请求易于使用。每个人都可以快速使用REST API。哎呀，您甚至可以打开浏览器并输入URL以查看数据，那么您将变得更具互动性吗？
• （几乎）任何编程语言都可以使用它。这是一种通用接口。从外来语言与SignalR交互似乎不太明显。
• 它具有很好的工具支持，例如http://petstore.swagger.wordnik.com/
• 这是一个很好的调试“接口”。您可以直接在浏览器中轻松监视传入和传出的消息，查看数据等。使用websocket和自定义库，并不是很明显，您必须显式地记录所有内容。