2
性能是不完全使用SignalR（网络套接字）来代替传统REST API的唯一原因吗？
我曾SignalR在多个项目中实现实时消息传递功能。它似乎工作可靠，并且非常易于学习使用。 至少对我来说，诱惑是放弃开发Web API服务，并将其SignalR用于一切。 我觉得这可以通过深思熟虑的设计来实现，如果可以的话，这意味着将需要更少的客户端代码。更重要的是，这将意味着将有一个单一的服务接口，而不是一个分离的接口，并且在最坏的情况下，可以将其连接起来而无需考虑何时渲染事物，等等。 因此，我想知道： 除了性能之外，还有其他原因不使用SignalR代替所有Web服务吗？ SignalR的性能是否足以引起人们的注意？ 能够将服务器端对象和服务定义转换为客户端服务访问代码而不用愚蠢的东西一直是我的梦想node.js。例如，如果我定义了一个有趣的对象InterestingObject以及该对象的服务，CRUD则InterestingObjectService可以定义到该服务的标准URL路由-例如“ / {serviceName} / {methodName}”，但是我仍然需要编写客户端代码才能访问服务。由于对象将被从客户端传递到服务器和背部，没有实际的原因有在客户端代码中显式定义对象，也无需显式定义执行CRUD操作的路由。我觉得应该有一种标准化所有方法的方法，这样就可以在假定服务访问从客户端到服务器再到服务器的工作透明的前提下编写客户端，就像我在编写WinForms或Java时一样Applet或Native App或您拥有的东西。 如果SignalR足以代替传统的Web服务使用，则它可能是实现此目的的可行方法。SignalR已经包含使集线器像我描述的服务那样工作的功能，因此我可以定义一个通用基础（CRUD）服务，该服务可以开箱即用地提供所有这些功能。然后，我几乎可以认为服务访问是理所当然的，这使我免去了重新编写代码以访问约定可以访问的内容的烦恼-更重要的是，我不得不花时间编写代码来定义如何对其进行更新。 DOM。 阅读我的编辑后，我觉得这可能有点荒谬，所以请随时问我是否对我的想法有疑问。基本上，我希望服务访问尽可能透明。