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.
On Friday, 29 August 2014 06:24:24 UTC+2, Reza Razavipour wrote: > > 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/7ae21c54-a5bc-40a6-9257-74617a11c524%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
