I just read Peldi's post on REST.After reading the article, a few things came to my mind as a Rich Internet Application Developer:
First off, when it comes to REST, things can get a little confused and the term ends up being used loosely. When you talk about "State Transfer" is that "Model State" , "View State", or "Application State" (the latter being a combination of both).
REST can be used very effectively when web services are being delivered, where the state transfer is that of "Model State". The Flickr REST API is a great example of this:
Template Flickr Request:http://www.flickr.com/services/rest/?method=flickr.test.echo&name=value
Flickr claims that this is the format of their REST API, but this is not in agreement with what is truly considered REST because it is triggering action, and not transfering state(all the time). I could use this API to delete photos, return photolists, and add tags to photos.
However, the point of the Flickr API is not to be human readable, it is instead a way to allow ubquitous intercommunication with any remote application that can communicate via HTTP. It is used primarily to transfer "Model State". Is it REST?, not completely, so maybe all the web 2.0 companies out there offering up REST API's should consider a new term.
So that takes me to "View State". REST is used to describle this as well. Over the years Flash developers like
Robert Penner, worked hard to develop ways to allow Flash content to interoperate with traditional web browser navigational mechanisms. By that I mean, Back/Forward Buttons, Bookmarking, or really just all history management in the browser.
The solution, which is now built into Flex as the HistoryManager, uses a hidden HTML frame that carries params on the url that gets communicated back to the SWF as hidden pages load in and out of that frame:
Flex History REST URIhttp://domain/flexapp/history.htm?&app=48a7&aa68-selectedIndex=0&1103-selectedIndex=0&d314-selectedIndex=0
The funny thing is, that this is extremely RESTful. You are transferring the state of the view very specifically. However, you are not really providing a pointer to any specific resource, you are just simply conveying the state of the UI that wraps an application that likely has a separate "Model State" not represented in this URI.
So that leads us to "Application State", and this is the state that Peldi and the others are discussing. This is when both the "Model State" and the "View State" are being conveyed in the same URI:
Teknision on Google Maps (ugly):http://maps.google.com/maps?f=q&hl=en&sll=37.0625,-95.677068&sspn=48.641855,82.441406&q=teknision+inc&ll=45.392566,-75.752578&spn=0.005304,0.010064&t=h&om=1Peldi's Delicious Links about APIs (beautiful):
http://del.icio.us/peldi/APIsNow whether the links are beautiful or not, both are very useful. but the real question is:
"Why is one beautiful and the others are not?"
The Delicious example is communicating a logical breadcumb of organizational structure, and that is why it is beautiful.
The Google Maps example is not beautiful because the parameters are siblings, not descendants. REST looks beautiful when representing a simple descending navigational structure, but looks awful when more and more siblings come into play. As a matter of fact, in a URI, siblings will block further decent.
It is due to this that REST is truly not the ultimate format for state transfer.
And this is where I conclude with the reason why Rich Internet Applications and REST(from a web browser perspective) has always been a complicated situation and will continue to be:
Web Browsers force us to communicate "Application State", where Rich Internet Applications don't really have a strong constant definition of "Application State". They instead manage "Model State" and "View State" separately and it is that that makes them so powerful and appealing. Because the Browser is the host for the RIA, the RIA is forced to find a way to separate the two states out of the constraints of the Browser enviornment.
Addition:
In a way REST is lovely, but it is lovely in it's simplicity. When it comes to Rich Internet Applications, we must remember that the concept of the RIA was developed because we believed that the traditional REST model of the Internet was not adequate to facilitate the experiences and applications we all wanted to deliver over the internet.
While I believe it is important for RIA developers to work hard to try and fit into a REST driven web, I think it is more imprtant to prove to the rest of the web industry that REST is not the answer to every problem, and is not powerful enough to communicate everything that we need to communicate.
