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? On Thursday, August 28, 2014 2:08:35 AM UTC-7, Floby wrote: > > 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. > > On Wednesday, 27 August 2014 21:38:03 UTC+2, greelgorke wrote: >> >> 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. >> >> Am Mittwoch, 27. August 2014 05:38:34 UTC+2 schrieb 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? >>> >>> >>> >>> -- Job board: http://jobs.nodejs.org/ New group rules: https://gist.github.com/othiym23/9886289#file-moderation-policy-md Old group rules: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines --- You received this message because you are subscribed to the Google Groups "nodejs" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/nodejs/5382f51a-a760-4a43-8f38-76eddfae686e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
