3 ms·
Yes, and that's REST+..., not REST. If you've got a websocket, you're explicitly making the design choice that client-side application state can live outside t
by regularfry 5y ago
Yes, and that's REST+..., not REST. If you've got a websocket, you're explicitly making the design choice that client-side application state can live outside the HTTP payload.
The key question is this: given a link and some subsequently-received websocket data, could a second client reconstruct the same application state given only a link? If the answer to that is "no", then what you have is not a system which supports HATEOAS. It's just not something people pay attention to once websockets are in the mix. Granted, you might get there by accident, depending on what you're doing with them, but I don't often see that as a design goal.
- capableweb 5y agoHTTP-Kit in Clojure-land has solved this beautifully with a unified interface for handling both WebSocket messages and HTTP requests, so using one function you receive requests/messages that you can act on, and responding to those also have the same interface. http://http-kit.github.io/http-kit/org.httpkit.server.html#var-Channel http://http-kit.github.io/http-kit/org.httpkit.server.html#v... I'm sure similar things exist in other ecosystems too, so it's not impossible.
- regularfry 5y agoI'm not sure I see how that solves the problem, beautifully or otherwise. How are links constructed?
- codemonkey-zeta 5y agohttps://http-kit.github.io/ https://http-kit.github.io/ The homepage is probably better to understand the project than the API reference provided above.