REST 4: Web App with some REST on a side

Probably my last post of the series inspired by the RESTfulweb services book.   This post is about these very few topics where I have problem in fully agreeing with the authors. 

JavaScript Ajax

More and more of web apps are Java Script heavy and end up moving data back and forth with Ajax.  The book suggest this to be a great opportunity for REST.  I have some skepticism.

I can be persuaded that SPA (single page load - applications with only one HTML page sporting an empty page body, and lots of JavaScript) are more likely to be implemented with true REST.   (Authors call these type of projects Ajax projects and make a point that these are really true Web Services under the hood.)   But I am still skeptical.

Web application development tends to focus on ... well  on the user interface development.  Unless project has explicit goal to create web service interface easily accessible by the 'rest' of the world,  the implementation will end up a REST-RPC hybrid at best.

I am probably repeating myself here. My point is that REST is not on the path of least resistance for Web App development.  Simply put: in today's task focused development a true REST will not make into the story line.  As long as JavaScript gets the data it needs and sever gets the data it needs from JavaScript the development goals are satisfied.  REST as part of Ajax will most likely only mean using GET, POST, PUT, DELETE verbs.  The data will likely be send in JSON format and will contain whatever is needed by the UI: and not a meaningful representation of a resource. The URLs will be constructed by JavaScript and will likely use ? and database IDs.  status codes 500 and 200 only (well maybe 404 and 401 but that will be about it) ...  

Grails withFormat and Rails respond_to

It seems that both Grails and Rails made it not very easy for the programmer to separate controllers serving the same URL base:  to have one for serving REST and a twin for serving web pages.

The seemingly easiest and most tempting alternative is to use withFormat (Grails) or respond_to (Rails) blocks of code.  The book seems to approve of the Rails respond_to method (Grails is not covered).
This is tempting because you can do stuff like this:

    def list() {
        def books = Book.list()

        withFormat {
            html { [bookList:books] } 
            json { render books as JSON } 
            xml { render books as XML }
        }
    }

I do not like this approach.  Here is why:

If your web application is serving HTML pages to the user the controller is already busy doing what is it supposed to be doing in the MVC web framework: flowing the pages (we are not talking Ajax here).

Page flow and serving REST uniform interface are 2 different problems and have very little in common.

Separation of Concerns?: Ironically, my first post about REST compared it to OO.

Let me rephrase this: in an MVC web application serving web pages it is the Controller's job is to decide what the user will see next.  In a RESTful Web Service it is the client responsibility to decide what to do or see next.  If there is a user sitting behind a REST client (it does not have to be) the UI presentation flow is the REST client responsibility. The difference is that of push vs pull.

Using the same controller for flowing pages and serving REST is mixing apples and oranges.

So my take on this is:  If you are writing a RESTfull Web Service and are using Grails or Rails than using withFormat/respond_to is a great idea.  You are serving different representations of the same thing and it is convenient to see the rendering logic for all of these representations in one place.

If you are adding REST on a side of a Web app, then keeping your REST logic together with page flow logic is a bad idea.

Concluding Remarks:

Reading the book was overall a great learning experience for me.  Hopefully I have managed to stir some unREST into my coworkers and friends with these posts.

I am not a REST expert.  I have still a lot to learn.  I am looking forward to discussing this stuff.

My next step should be to read up on semantic web but this will need to wait a bit ... I got myself a haskell book...