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