RESTful server and websockets

[Reza Razavipour]

I feel that a server that provides a RESTFul API should not support websockets connections. 

Websocket connections implies stateful, server is aware of a persistent connection to a client. A RESTFul server implies that there is no notion of a client, only request and response and nothing more as it pertains to the client.

We have a case where the clients, AngularJS code, communicates with a REST node server. Now we have a feature of server "updating" the clients of an event. Client can polls, very frequently, for the event happening. Or enter the websockets and the notion of publisher/subscriber. To provide that and to stay pure to the RESTFul premise, we can add a secondary node server for this purpose of pub/sub model.

Am I the only one feeling like mixing RESTful API and websockets is mixing metaphors and should be avoided?

Thoughts?

[greelgorke]

i'd go for a separate server. for several reasons, not only for separation of concerns. a rest-server and a pub/sub server can have differend load and usage profiles, and might need separate scaling strategies.

[Floby]

That first answer is right. The separation of both applications would be motivated more by a difference in load usage and scalability options.

WebSockets can somehow violate REST principles. It all depends on what your resource is. REST works around resources YOU define. If you define your resource to be a CRDT for example, then a websocket is perfectly fine for it. However this is a very tiny use case.

In your case, since you're only sending events, I would suggest using EventSource (Server-Sent Events) instead. These do not involve HTTP upgrades, are a very simpler protocol and only differ from usual HTTP by a Content-Type header. EventSource doesn't violate REST principles since you define your resource as being "the events in order from that starting point". Since you're only getting notifications from that channel, updates would be made using your existing RESTful interfaces.

That's also how CouchDB _changes feed works and how hoodie.io is built.

[Reza Razavipour]

I feel the way that websockets violate REST principle is the notion of the server knowing about a client and its "state" in the sense that the server is aware of a "persistent" client waiting for to be told of an event. this is different that the REST model of request/response.     To me it is mixing stateless and stateful.

Agree?

[Floby]

Yes, however holding a websocket is more or less like holding a TCP socket (that's the whole point of it) which your server already does anyway. WebSockets are an HTTP Upgrade in the implementation but is the philosophy it is really more like a downgrade (and implemented as such when an HTTP proxy is in the picture). So it really all depends on what you do with them. There's no official way to do RESTful stuff at the Connection Layer, but you surely can find one. REST is not HTTP, so you can follow pure REST principles over a websocket as much as you can follow them over a TCP connection.