Is web-based real-time communication incompatible with REST paradigm?

Question

Web-applications experienced a great paradigm shift over the last years.

A decade ago (and unfortunately even nowadays), web-applications lived only in heavyweighted servers, processing everything from data to presentation formats and sending to dumb clients which only rendered the output of the server (browsers).

Then AJAX joined the game and web-applications started to turn into something that lived between the server and the browser.

During the climax of AJAX, the web-application logic started to live entirely on the browser. I think this was when HTTP RESTful API's started to emerge. Suddenly every new service had its kind-of RESTful API, and suddenly JavaScript MV* frameworks started popping like popcorns. The use of mobile devices also greatly increased, and REST fits just great for these kind of scenarios. I say "kind-of RESTful" here because almost every API that claims to be REST, isn't. But that's an entirely different story.

In fact, I became a sort of a "REST evangelist".

When I thought that web-applications couldn't evolve much more, a new era seems to be dawning: Stateful persistent connection web-applications. Meteor is an example of a brilliant framework of that kind of applications. Then I saw this video. In this video Matt Debergalis talks about Meteor and both do a fantastic job! However he is kind of bringing down REST API's for this kind of purposes in favor of persistent real-time connections.

I would like very much to have real-time model updates, for example, but still having all the REST awesomeness. Streaming REST API's seem like what I need (firehose.io and Twitter's API, for example), But there is very few info on this new kind of API's.

So my question is:

Is web-based real-time communication incompatible with REST paradigm?

(Sorry for the long introductory text, but I thought that this question would only make sense with some context)

Answer 1

Stateful persistent tcp/ip connections for web-applications are great, as long as you are not moving around.

I have developed a real-time web based framework and in my experience I found that when using a mobile device based web browser, the IP address kept changing as I moved from tower to tower, or, wi-fi to wi-fi.

When IP addresses keep changing, the notion that it is a persistent connection evaporates rather quickly.

The framework for real-time web-app has to be architected with the assumption that connections will be transient and the framework must implement its own notion of a session while the underlying IP connection to the back-end keeps changing.

Once a session has been defined and used in all requests and responses between clients and servers, one essentially has a 'web connection'. And now, one can develop real-time web based apps using the REST paradigm.

The back-end server of the framework has to be intelligent to queue up updates while IP addresses are undergoing transitions and then sync-up when tcp/ip connections has been re-established.

The short answer is, 'Yes, you can do real-time web based app using the REST paradigm'.

If you want to play with one, let me know.

Answer 2

I'm very interested in this subject too. This post has a few links to papers that discuss some of the troubles with poorly-designed RPC:

http://thomasdavis.github.com/2012/04/11/the-obligatory-refutation-of-rpc.html

I am not saying Meteor is poorly designed, because I do not know much about Meteor.

In any case, I think I want the best of both "world". I want to benefit from REST and all that it affords with the constrained generic interface, addressability, statelessness, etc.

And, I don't want to get left behind in this "real-time" web revolution either! It's definitely very awesome.

I am wondering if there is not a hybrid approach that can work:

RESTful endpoints can allow a client to enter a space, and follow links to related documents as HATEOAS calls for. But, for the "stream of updates" to a resource, perhaps the "subcription name" could itself be a URI, which when browsed to in a point-in-time single request, like through the web browser's address bar or curl, would return either a representation of the "current state", or a list of links with the href for prior states of the resource and/or a way to query the discrete "events" that have occured against the object.

In this way, if you state with the "version 1" of the entity, and then replay each of the events against it, you can mutate it up to its "current state", and this events could be streamed into a client that does not want to get complete representations just because one small part of an entity has changed. This is basically the concept of an "event store", which is covered in lots of the CQRS info out there.

As far as being REST-compatible, I believe this approach has been done (though I'm not sure about the streaming side of this), I cannot remember if it was in this book http://shop.oreilly.com/product/9780596805838.do (REST in Practice), or in a presentation I heard by Vaughn Vernon at this recorded talk in QCon 2010: http://www.infoq.com/presentations/RESTful-SOA-DDD.

He talked about a URI design something like this (I don't remember exactly)

host/entity <-- current version of a resource host/entity/events <-- list of events that have happened to mutate the object into its current state

Example:

host/entity/events/1 <-- this would correspond to the creation of the entity host/entity/events/2 <-- this would correspond to the second event ever against the entity

He may have also had something there for history, the complete monent-in-time state, like:

host/entity/version/2 <-- this would be the entire state of the entity after the event 2 above.

Vaughn recently published a book, Implementing Domain-Driven Design, which from the table of contents looks like it covers REST and event-driven architecture: http://www.amazon.com/gp/product/0321834577