I must be missing something here… . I went ahead and looked at Web Sockets since it sounded like a great solution to improve the communication from client to server instead of HTTP. It seems like the WebSockets send API only allows to send either binary data or a text string. And this got me wondering, how the frack do you implement REST over WebSockets in a uniform way?

First and foremost, how do you represent a URI? Second, how do you represent the HTTP methods (GET, PUT, POST, …)? And last, how do you represent HTTP uri parameters and headers? It seems like maybe a solution for this is to built some sort of schema into the content that goes into that text string. Something like a JSON string that has a “uri” field, and “params” and so on. But thats annoying, since with HTTP, you can create very simple gateways that simply use the headers or parameters without needing to parse the body…

Am I missing something here? Why doesn’t WebSockets send method have the notion of a URI and headers (which can be passed in optimized binary format for fast parsing)? It seems like REST has taken a beating with WebSockets…

On top of that, it seems like (and correct me if I’m wrong here) you register a listener that accepts all responses. If we want to simulate an async request response scenario, the client needs to create a unique request id, and the server must send it back so the client will correlate a response to a specific request.

If all the above holds, it means that people will reinvent what both REST and async request response communication does and probably not in a uniform manner. Do we now need a REST over WebSockets specification?

p.s. I understand the benefits of WebSockets for comet style, long polling HTTP requests, just want to use it for typical async RESTful request response type instead of HTTP.