我正在使用大型复杂服务器端组件的项目的客户端工作。客户端将作为移动应用程序部署在其他环境中。
对于客户端 - 服务器通信，有两种相反的观点：
就个人而言，我不介意采用哪种方法，只要最终的API经过深思熟虑，可理解和可扩展。
从基于C ++的复杂应用程序之前使用TCP套接字的经验来看，我知道自己的语法/协议会很快变得不一致，混乱和难以管理。
是否存在使用Web套接字进行客户端 - 服务器通信的通用样式或协议（如REST或SOAP）？是否有关于设计自己的客户端 - 服务器通信方案/协议的指南或最佳实践？
答案 0 :(得分：9)
你看过WAMP吗？
从上面的页面：
WebSocket协议已内置于现代浏览器中，并提供双向，低延迟的基于消息的通信。但是，因此，WebSocket它的级别很低，只提供原始消息传递。
现代Web应用程序通常需要更高级别的消息传递模式，例如Publish＆amp;订阅和远程过程调用。
这是WebSocket应用程序消息传递协议（WAMP）进入的地方。 WAMP在一个协议中将RPC和PubSub的更高级别的消息传递模式添加到WebSocket。
从技术上讲，WAMP是一个正式注册的WebSocket子协议（在WebSocket之上运行），它使用JSON作为消息序列化格式。
WAMP采用开放的Web标准，其设计易于使用且易于实施。
答案 1 :(得分：3)
没有任何意图的轻微，Jesse，我会在经过一些研究后回答我自己的问题。
我没有遇到任何REST的等价物。目前的趋势似乎是使用JSON来发送和接收对象。这在面向JavaScript的世界中似乎是明智的，并允许消息在收到时立即更新数据。
例如：
我试着按照这些方式编写自己的协议。但是，我遇到的最完整定义的协议是JSON-RPC。关于该协议的另一个好处是，如果您在混合套接字和HTTP应用程序中编写，则可以在HTTP和WebSockets上使用相同的消息传递系统。
我遇到的另一种方法是将消息传递协议“移植”到WebSockets（无论它们是否使用JSON）。因此，例如，XML-RPC（JSON-RPC所基于的）可以相当简单地重新实现，以便在套接字上使用。实际上，SOAP也可以通过套接字重新实现。
虽然上面的一个链接是STOMP，但我遇到了一个很好的小协议。这也可以移植 - 和indeed has。
答案 2 :(得分：0)
假设java，我喜欢Cometd（www.cometd.org）作为一种消息传递机制，它位于http，websocket甚至spdy等协议之上，或任何新的协议都会出现在派克之上。类似的东西的吸引力在于您编写了该api并且它无缝地分析了给定客户端/服务器组合的最佳底层协议。如果您使用的是旧的IE，那么它会恢复正常的正常http，但如果它是新的IE，那么它可能会选择websockets。如果您使用的是chrome或firefox，那么您将获得spdy，当http / 2.0登陆基于spdy时，您将能够更新cometd并免费获得。此外，在websockets之上使用更高级的协议，您可以获得诸如通过隧道和丢失连接之类的信息恢复。适用于聊天应用程序或想要通过有序消息等维护状态的应用程序。我喜欢这些功能的bayeux协议（这是cometd实现的）。
所以个人而言，我并不认为REST和websocket是竞争或反对，他们是不同的生物。 REST是一种解决方案，它由HTTP风格的无状态环境构成，并且使用URL的约定，而websocket是http的替代协议。使用REST，您不太可能会关注自己预热TCP连接以获得更好的吞吐量，但这些事情在可能更长寿的连接（例如websocket或spdy）中变得更加常见。虽然带有流水线技术的http / 1.1是一个选项，但由于支持不足，直到移动浏览器最近默认开始使用它，因此它没有达到它的潜力。