After watching Matt DeBergalis's meteor talk, it confirmed what I have been thinking about REST for a long time. REST is not fit for the next generation of smart client applications because it has not been designed for smart clients.

I like to think of a web service as a restuarant.

In the REST world, our restaurant looks like a ticketing office with a bunch of service counters. We would have a map in front of the restaurant telling our customers of our menu as well as the counters to pick up each item. In order to get a particular item, our customers would need to go to a particular counter. For example:

  • if they wanted porriage, they would go to one counter
  • if they wanted bananas, they would go to another counter
  • if they wanted beef and gravy, they would have to first go to the beef counter, then go to the gravy counter.

In the real world, we would expect this restaurant to go out of business very quickly. It's a model for feeding monkeys not for servicing intelligent interactions.

The whole argument of using REST usually ends up on this critical point: 'We use REST because it can be cached by proxies.'

Really? This argument was valid when networks were slow. Now that we can download a full HD movie in the space of minutes, it doesn't quite hold true anymore. When I walk up to a counter to be serviced, I expect that the staff behind the counter are competent enough to be able to manage all my requests. I expect the same of a web-service. I only want to deal with one service counter, not twenty.

I believe that 6 major components are needed to do a full stack, smart client application:

  1. persistence (storage and query)
  • documents/orm (conversion to tree-like datastructures)
  • data authorization (once authenticated)
  • pub/sub (websocket communications)
  • client db (client-side caching and querying)
  • templating (presentation level)

The meteor stack is made out of 4 components that take care of 5 out of 6 things:

  • mongodb (1 and 2)
  • ddp (4)
  • mongo on the client (5)
  • spark (6)

I will not go into the problems of authorization as yet, but will do so in a little bit. This again is something that REST is really not designed for. I think that the meteor.js solution also lacks a compelling design for data authorization.

I'm in full agreement on the meteor.js philosophy, but I don't entirely agree on the technology stack. For me, its clojure, not javascript. My clear favorite for the database is datomic because of its query power and also because I don't believe document databases are flexible enough for reporting. My clear favorite for templating is with angular.js. I really like ddp. I am still unsure about what the best way is to go about client-side caching. So a competiting real-time clojure webstack like meteor.js could potentially be:

Once again, I missed authorization (3). Authorization is a much harder problem than authentication because it concerns every aspect of your application. It is usually always baked into the application. There is currently no way to do data-level grainularity authorization control. I am currently working on this problem but unfortunately, the code is closed for now. But here is a brief sketch of what I have been working on:

Web apps have come a long way since the first webpage. It can be seen in the table below that more and more functionality is being moved onto the server.

We see in the next figure the web application in 2005. Back then, it was still mainly the server which had all the power. It was the server that maintained state, generated webpages, collated data.. etc. The client interacted with the database only within a narrow set of views. Most of the presentation and business logic is rendered on the server.

Current webapps started to change in 2010 with the popularization of html5 and css3. Clients started to take over the presentation logic and some of the business logic. We see here that the webapp model in 2010 is fundamentally the same as that in 2005, but there are now just more parts to the system. Presentation has moved onto the client with mobile and web ui frameworks. Alot of business logic that is not transactional in nature has also moved into the client.

Going forward, it should be assumed that the future is client-dominated. The 2010 model is unsustainable for what we want to build. The server is looking more and more like a database. With powerful browsers, the complexity of client-side applications running within the browser has taken the load off of the server. The business and control logic can be implemented on the page, and so whilst this is great for the consumer, it is a real nightmare for the application developer.

The more flexible the client becomes, the more query power is demanded of the server. Therefore, developers are required to expose more and more of the innards of the system and the server then takes on the role of a database. However the database was only built to house data. It does not include a security model. Therefore, the application developer then has to implement security checks for each interface that is exposed. This is bad news for the developer if he has to implement a RESTful API because it is analogous to building twenty different service counters that all sort of do the same thing.

With the current advancement in webservice development, the most critical problem is in being able to secure our queries at the data-level. We need to be able to build databanks that clients can access. These secured database systems will give us the full power of query but also allowing us to secure the content depending upon the person that is asking the question.

Below is the sketch of the proposed future webapp model for 2015+

Example: A client and sysadmin should both be able to ask for a set of results to our databank ["/list" :account] and depending on the credentials of the user, different set of results should come up.

If a client asks ["/show" {:account {:user "Bob"}], if he is Bob, he should be able to get his account details. If he is not, he will be denied. But if an admin asks, he should be able to get the details of any client.

If a client says ["/update" :account {:account {:address "123 Red Rd"}}], the databank will update the address.

If a client says ["/update" :account {:account {:password "secret"}}], the database will not store the password but the hash.

One might say... we definitely can do that in REST. NO. Those particular ones may be able to be implemented, but not the one that are just SLIGHTLY complicated.

["/list" {:student {:siblings (< 2)
                    :classes/type :art}}]

In short Secured, personalised, CRUD operations are the future to a more simplified web. I'm pretty sure that the future will not be completely REST-less but the query power we need cannot be implemented on REST, therefore the future will definitely not be REST-ful either.