REST is dead! Long Live Socket.io!

I’ve been working with socket.io recently and have been very impressed with it’s capabilities and simple API.  I’ve not been impressed with the documentation–it’s like someone at the fortune-cookie printing office decided to write a tech manual.

I’ve been working on a few projects in my spare time that involve real-time updates pushed from the server to the client.  Over the years I’ve become a big fan of REST and it’s simplicity and flexibility.  But, polling has always sat poorly with me: it’s cumbersome and network-inefficient.

My initial design approach was to use REST for the bulk of the API and merely push out notifications with socket.io.  However, once I started using socket.io, I was impressed with it’s ease-of-use and flexible nature.  As I dug deeper into socket.io’s capabilities I realized it didn’t just support traditional pub/sub communication.  Through the use of ‘acknowledgements’ and rooms, it also supports RPC-like communications directly between a client and server .

This was when the proverbial light-bulb went off!  If socket.io supports distributed function calls along with pub/sub, why have the complexity of two different APIs?  Native web-socket support exist in nearly all modern browsers (see this chart) and I don’t see any of the modern front-end frameworks (aurelia, angular, react, etc.) throwing up any roadblock to the use of socket.io in lieu of REST calls.

In reality, this isn’t just about socket.io either.  There are other bi-directional network communication frameworks and standards such as crossbar and WAMP that can support full-featured APIs.  It’s really about a transition from a uni-directional, procedural style of API to a bi-directional API that supports both procedural and object-oriented-ish approaches (dynamic creation of rooms can allow for object-related state to be maintained within the server).

I’m starting work right now on a small library that facilitates dynamic registration of RPC providers to extend this idea of bi-directional function calls between distributed systems to allow for dynamic registration of function providers (dependency injection for distributed systems).

Obviously REST still serves a purpose and provides benefits such as caching.  But, if you’re creating a seriously interactive application that requires bi-directional communication, it may be worth simplifying your API and improving your network efficiency by using something like socket.io for your API.

What do you think?  Are bi-directional API’s built on technologies like socket.io and websockets the future?



    1. @weagle08 – I agree. REST has several definite advantages, including caching and a proven, well-understood architecture. I think socket.io is great for bi-directional eventing and situations where low latency is important.

    1. @ashley – I don’t know much about GraphQL. I’ll have to take a look at it. Thanks for the suggestion.

Leave a Reply

Your email address will not be published. Required fields are marked *