Web Design
The State of Things
Sunday, October 5th, 2008 | | No Comments
I know I’ve made a mistake in the design of a REST style application if it can’t handle the same user logging on from two places at the same time. It is easy to assume that there is no good reason for a user to do such a thing and therefore dismiss the hard work of fixing any related problems. But that problem is just a good way to test how your application behaves over an unreliable network (heretofore called “The Web”). Just as easy as ignoring that mean user with his two simultaneous sessions, is ignoring the fact that The Web is unreliable. Any good web application design should account for that. The problems associated with this problem mostly have to do with separation of application state from resource state.
As an example consider a blog where users must be logged in to comment. In this system there is a create comment page. This page adds the comment, when submitted, to the article that the user was viewing before he went to the create comment page.
If application state was managed on the server, there might be a variable stored in the user account that identifies the post that that user last viewed. This variable would be referenced when the user submits a comment, with the comment being added to whichever article that variable contains.
Now, how can that go wrong? Say a user, let’s call him Steve, logs in to the blog. Steve reads an article that he would like to comment on, so Steve goes to the create comment page. While composing his comment, Steve remembers another post that was related that he would like to quote. So Steve opens a new tab and navigates to that post. Steve then goes back to the tab with the comment form, finishes it and clicks the submit button.
In this scenario, the comment, since it relied on the server side variable to determine which article the comment was for, would end up on the second article, the one Steve was viewing in the second tab, because that was the last viewed article, not the one he was actually trying to comment on.
In a better design, the article that a comment was meant for would be manged on the client side, it being application state, possibly as an item in the comment form.
Obviously this is a simple example, but generally the ways in which this problem arise can be reduced to such a simple scenario. They generally involve many more steps and much more complicated interactions, but they all involve requiring the server to know the current state of the client.
See also: State in Web application design