首先，我没有敌意也没有疏忽，只是想知道人们的想法。我正在研究客户端和服务器之间的双向通信；客户端是一个网络应用程序。在这一点上，我有几个选择:MS 专有的双工绑定(bind)，据我所知不可靠和不自然: cometd 和网络套接字(用于支持的浏览器)。
我知道这里以其他方式提出了这个问题，但我对该方法有一个更具体的问题。考虑到 Web 套接字是客户端，客户端代码位于 JavaScript 中。直接用 JavaScript 构建大量应用程序真的是有意吗？为什么 W3C 不在 Web 服务中这样做？如果我们能够使用 SOAP 来提供契约(Contract)并定义事件以及涉及的现有消息传递，这不是更容易吗？到目前为止，感觉就像棍子的短端。
为什么不让它变得简单并利用 JS 的动态特性并将大量代码留在其所属的位置......在服务器上？
代替
mysocket.send("AFunction|withparameters|segmented");
我们可以说
myServerObject.AFunction("that", "makessense");
而不是
...
mysocket.onmessage = function() { alert("yay! an ambiguous message"); }
...
我们可以说
...
myServerObject.MeaningfulEvent = function(realData) { alert("Since I have realistic data...."); alert("Hello " + realData.FullName); }
...
HTML 5 花了很长时间才站稳脚跟……我们是否在错误的方向上浪费了大量精力？想法？
最佳答案
在我看来，您似乎还没有完全掌握 Websockets 的相关概念。例如你说:
Considering web sockets are client-side
事实并非如此，套接字有两个方面，您可以将它们视为服务器和客户端，但是一旦建立连接，区别就变得模糊了——您也可以将客户端和服务器视为“对等体” "- 每个人都可以随时写入或读入连接它们的管道(套接字连接)。我怀疑您会从更多地了解 HTTP 在 TCP 之上的工作中受益 - WebSockets 在这方面与 HTTP 相似/类似。
关于 SOAP/WSDL，从围绕 TCP/WebSocket/HTTP 的对话的角度来看，您可以将所有 SOAP/WSDL 对话视为与 HTTP 相同(即正常的网页流量)。
最后，记住网络编程的堆栈性质，例如 SOAP/WSDL 看起来像这样:
SOAP/WSDL
--------- (sits atop)
HTTP
--------- (sits atop)
TCP
WebSockets 看起来像这样
WebSocket
--------- (sits atop)
TCP
HTH.
关于soap - 为什么 Web Sockets 不使用 SOAP？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/4007439/