3 ms·

> About the only thing that REST over HTTP doesn't provide is sessions, but JWTs and OAuth now handle most of that. I would disagree. HTTP with REST is half a

> About the only thing that REST over HTTP doesn't provide is sessions, but JWTs and OAuth now handle most of that. I would disagree. HTTP with REST is half a communications protocol. The server can't push data. There are hacks around this but it's not REST as defined by the dissertation. HTTP and REST took sockets and lobotomized them. They work well where you don't need duplex communication but the tragedy is that they have been forced into solutions where they don't fit because lowest common denominator. Think of how much simpler and more flexible a world we would live in if every web server behaved similarly to a message broker, for example. (GraphQL does this, so there is hope).

drran 5y ago
Web sockets are used now to push data to clients. REST+WS is a good combo.
- 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 ago
    HTTP-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 ago
      I'm not sure I see how that solves the problem, beautifully or otherwise. How are links constructed?
      - codemonkey-zeta 5y ago
        https://http-kit.github.io/ https://http-kit.github.io/ The homepage is probably better to understand the project than the API reference provided above.
- rswail 5y ago
  web sockets are used to push messages, but the messages end up being half-assed representations of what should be media types. There's no reason that REST can't be bi-directional, but it means that each client is also a server. Most people don't write code like that.
rswail 5y ago
In REST terminology, there's nothing particular special about a "client" or a "server". Clients make requests, servers respond. There's nothing to stop the "server" connecting to the "client" and making requests to it to "push" data. REST as a style is not particularly well suited to streams of data, which is what web sockets sort of solve in an unstructured way.

drran 5y ago

Web sockets are used now to push data to clients. REST+WS is a good combo.

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 ago
  HTTP-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 ago
    I'm not sure I see how that solves the problem, beautifully or otherwise. How are links constructed?
    - codemonkey-zeta 5y ago
      https://http-kit.github.io/ https://http-kit.github.io/ The homepage is probably better to understand the project than the API reference provided above.
rswail 5y ago
web sockets are used to push messages, but the messages end up being half-assed representations of what should be media types. There's no reason that REST can't be bi-directional, but it means that each client is also a server. Most people don't write code like that.

rswail 5y ago

In REST terminology, there's nothing particular special about a "client" or a "server". Clients make requests, servers respond. There's nothing to stop the "server" connecting to the "client" and making requests to it to "push" data. REST as a style is not particularly well suited to streams of data, which is what web sockets sort of solve in an unstructured way.