The recent interest in AJAX (or however else people prefer to call client-side applications hosted in web browsers) has made me thinking about its relation to REST. Its current popularity for building Web applications is indisputable since all major players in the Web applications space build and/or experiment with applications that make use of the approach.
However, AJAX promotes a style of Web applications that, I believe, violates the principles of REST. Still, I haven’t heard any of the REST purists complain. Is this because AJAX “demonstrates” that the architectural superiority of the resource-oriented Web prevails over other styles of distributed application development (e.g. service-orientation)? How come we see attacks against SOAP and the WS-* world and not AJAX-based applications?
The Web is a hypermedia application. According to REST, following a link you should be transferred to a state representation which is associated with a particular URI (in the case of the Web, a URL). As it happens, together with that state representation we may also get some code that our hypermedia document viewer (the browser) executes. Depending on the interactions with the end-user, another program, the environment, etc. the executed code may make use of asynchronous calls to change the represented state that our viewer has loaded. It does so by usually fetching more state, possibly in a REST-friendly way (i.e. HTTP requests). However, during the user-application interactions, the URI remains the same even though the state representation that is rendered on our screens has obviously changed. Now, some AJAX applications may force a change in the URI effectively simulating a state transition but most of the ones I have used do not.
Check Google maps as an example. As you zoom in/out the represented state changes; the client-side application fetches different data as a result of the user’s actions. However, the URL remains constant. You have to follow a specific link on that page in order to get a URL that represents your current state. Surely this is not what Roy Fielding had in mind when he defined Representational STate Transfer. No?
Don’t get me wrong. I don’t disagree with the AJAX approach. On the contrary; I believe that rich client-side applications are very important. Such applications may offer rich interaction models with end-users that can go beyond the ones based on Web page transitions. Information is exchanged between clients and supporting services via asynchronous messaging. Effectively this is a model for Web applications closer to MEST rather than REST (we still need to think of the client-side applications as services in order to fully comply with the MEST principles). I believe that the introduction of XAML and similar technologies will allow us to do even more interesting things at the client side. If you’ve played with Google‘s Virtual Earth you’ll see how powerful is the combination of asynchronous messaging and client applications providing a rich end-user experience.
So, what to the RESTferians think? Am I wrong in my assessment? If yes, then please let me know why. If not, then why haven’t we seen the same level of dissatisfaction against AJAX that we have seen against service-oriented architectures and Web Services?
7 responses to “Why I think AJAX breaks REST”
I’ve read your MEST page a couple of times, but still don’t really get it. How about providing some examples that really set it apart from REST? Are there any MEST systems in the wild?
Hi Savas, I think you’re mixing different things. Your web browser and the Web server interact in a RESTful way. Your Javascript code and your web application may or may not interact in a RESTful way. Having one enable the other doesn’t violate any principles.
If I built a MESTful application sending embedded JavaScript in my SOAP messages that initiated some other (MESTful, RESTful or whatever) communication, would that make it less MESTful?
Parand, I will try to post in a separate entry examples and more explanation as I start preparing the MEST paper. In the meantime, please feel free to email me with questions.
Hey Stefan, MEST does not assume a hypermedia application and as a result does not suffer from the same problem. The Web is a hypermedia application though. AJAX effectively breaks that constraint. As an example… If I zoom in to the UK while I interact with Google maps, I have created a state representation (the one displayed on my screen). That state representation has not been cached anywhere. Instead, it’s an aggregation of many state representations that one has replaced the other without having gone through a complete state transfer. Instead, the web browser-hosted application has done some magic. I don’t think that just because HTTP is used to transfer XML documents back and forth it means that the REST principles are not broken.
I think the need to introduce solutions like this illustrates a problem with REST and its reliance on the hypermedia model.
But it could be just me :-))
Savas,
I disagree. AJAX interactions can be cacheable (and indeed, this is one of the big advantages of Google Maps; each individual tile can be separately cached, and recombined in many, many different views). The fact that some AJAX applications don’t surface a distinct URI for each state says that either a) the application author doesn’t judge that state important enough to merit a URI, or b) that application is badly architected.
Note that both of these are judgement calls. REST doesn’t require *every* state to have a corresponding identifier; witness HTML forms. Also, note that Google Maps (not to overuse an example) allows you to get a URI for each state (although, granted, it’s not in the browser bar).
So, AJAX itself isn’t the anti-REST; it’s just that it can be used in unRESTful ways, much as any other pattern in HTTP.
Hey Mark,
I think we are in agreement. It’s the way that AJAX is used that can break the REST principles. However, I argue that AJAX promotes an unRESTful way of doing things because developers/architects have realised the added benefits.
Please note that when I was talking about caching state I was referring to the end result and not the individual requests. That end result is a combination, at the client side, of the retrieved states which were individualy retrieved, not a new state to which the hypermedia application moved to through a request to a URI.
I agree that AJAX violates REST. REST views the possible set of all pages as separate states of a finite state machine. Each state is labelled with a distinctive URL. AJAX allows many states to have a single URL, thus violating REST. Note that with AJAX, the current state of a page cannot necessarily be recovered by bookmarking that page and later clicking on that bookmark.
My understanding of REST is that the “State” referenced in the acronym is the state of the client, and that the client transitions between states by manipulating representations of resources on the server. The whole point is to keep the application state on the client in order to achieve, among other things, scalability.
If what I say is correct, then what is the problem with Google Maps exactly? The server doesn’t transition between states because nothing on the server changes. The client transitions between states (i.e. zoom levels), but please take into account that: a. the end user would surely be aware of this because they get visual feedback, and b. as yu wrote Google Maps does include a reusable idempotent URL (see “link to this page”).
I do agree with your indirect criticism of “REST purists” though. REST is a nice theory and all but in practice most web apps do keep some sort of client state on the server (such as a user’s preferences etc.) It’s really no big deal.