reza
reza

Reputation: 6358

Is RESTful server and use of socket.io contradictory?

I am developing a node/express RESTful server with normal routes and HTTP request and response. Now I am asked to extend the server to provide near real time data to clients using socket.io or some such thing.

I feel like the real time update requires a client and serve connection management and client state management on the server and that on its own is orthogonal to the RESTful aspects of my server. For a client, to get continuous data feed from a RESTful server, the client has to "poll" for it.

Is my statement correct? If not, is there a pattern for providing the two features?

Upvotes: 0

Views: 122

Answers (2)

Dan Kohn
Dan Kohn

Reputation: 34327

No, there's no contradiction. Each HTTP request takes a round-trip to set-up, and many more if you support SSL (which you should), or do most forms of authentication. Socket.io lets you minimize those setups, by leaving the connection open and authenticated, ready for the next request. You could do something fancy with the 100 Continue header, following section 8.2.3 of the spec: http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html

But, just doing normal RESTful https pull requests over socket.io should show a meaningful decrease in latency, by minimizing the need to re-establish connections. Of course, implementing full server push support will lower latency even more.

The tradeoff is increased complexity (though socket.io can be implemented in Express in a few lines), and increased memory consumption by leaving sockets open.

Upvotes: 0

T McKeown
T McKeown

Reputation: 12847

Correct, RESTful services are contrary to the stateful client/server connection needed to give real time I/O. Without knowing how much data your talking about RESTful would be very expensive in I/O.

Upvotes: 1

Related Questions