我正在处理具有大型复杂服务器端组件的项目的客户端。客户端将在其他上下文中部署为移动应用程序。
对于客户端-服务器通信，有两种相反的观点：
就个人而言，我不介意采用哪种方法，只要生成的 API 经过深思熟虑、易于理解和可扩展即可。
根据之前在复杂的基于 C++ 的应用程序上使用 TCP 套接字的经验，我知道自己滚动的语法/协议会很快变得不一致、混乱且难以管理。
是否有任何通用样式或协议（如 REST 或 SOAP）用于使用 Web 套接字进行客户端-服务器通信？在设计您自己的客户端-服务器通信方案/协议方面是否有任何指南或最佳实践？
【问题讨论】：
标签： sockets web-applications websocket protocols rpc
你看过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，但我遇到了一个不错的小型协议。这也可以移植 - 和 indeed has。
【讨论】：
假设使用 java，我喜欢 Cometd (www.cometd.org) 作为一种消息传递机制，它位于 http、websocket 甚至 spdy 等协议之上，或者任何新协议出现。类似的东西的吸引力在于您编写该 api 并且它无缝地整理出对于给定的客户端/服务器组合的最佳底层协议是什么。如果您使用的是旧 IE，那么它会恢复到正常的正常 http，但如果它是新 IE，那么它可能会选择 websockets。如果您使用的是 chrome 或 firefox，那么您将获得 spdy，当基于 spdy 的 http/2.0 登陆时，您将能够更新 cometd 并免费获得它。此外，在 websocket 之上使用更高级的协议，您可以在通过隧道和失去连接等情况下获得消息恢复等功能。适用于聊天应用程序或您希望通过有序消息等维护状态的应用程序。我喜欢针对这些功能的bayeux 协议（这是cometd 实现的）。
所以就个人而言，我并不认为 REST 和 websocket 是竞争或对立的，它们是不同的生物。 REST 是一种诞生于 HTTP 风格的无状态环境并玩弄 url 约定的解决方案，而 websocket 是 http 的替代协议。使用 REST，您不太可能会担心预热 TCP 连接，以便获得更好的吞吐量，但这些事情在可能更长寿命的连接（如 websocket 或 spdy）中变得更加常见。虽然带有流水线的 http/1.1 是一个选项，但由于支持乏善可陈，直到最近移动浏览器才真正开始默认使用它。
【讨论】：