Dave Thomas discusses an interesting architecture for web applications. You create two applications – one that does all the work you need and represents its data as XML, and one that presents it in a browser-friendly format. The reasoning behind it is that web browsers are stupid. Fat clients can read and interpret XML directly from the main app and do whatever they want based on it. Display it in editable form, post it back to the server to create or update resources, etc. Browsers will need to interact with the presentation app to help users manipulate the resources.
I think it’s a cool idea. I doubt most apps need it, but once you get to a point where you’re dealing with lots of different resources, it might be nice to have. It lets you keep the business logic completely separate from the presentation layer. Personally, MVC works just fine at this point, but I can envisage a scenario where RADAR would be useful.
What I don’t understand is why people have an issue with the ;edit-style URLs – http://example.com/articles/1;edit. Dave writes:
However, I personally think it was optimistic to try to treat the two styles of interaction (smart and dumb clients) using the same protocol. The ugliness of the ;xxx appendages was a hint.
Robert Hahn addresses the URL problem in his 3 Rules of URI Design. I happen to like Rule #1, I use Rule #3 where it makes sense, and I think he’s dead wrong with Rule #2.
When you request /articles/1;edit, you’re simply requesting an editable representation of the resource located at /articles/1. Just like /articles/1.xml gives you an XML representation of that resource. When you tack on ;edit, you just return some HTML that the browser renders as a form.
Perhaps some of the mistrust stems from the name “edit” being used. Critics claim that it’s mixing an action into the URL. However it’s pretty clear that no action is taken:
|
|
1.million.times { GET /articles/1;edit } |
Part of the beauty of the web is that GET requests are guaranteed to be non-destructive.[1] So no matter how many times you get /articles/1;edit, you’ll never modify it, you’ll never create another article, you won’t accidentally delete it, you won’t trigger a notification that mucks with some other resource…nothing happens. There is no action. You just get the article, exactly like you wanted to do. And hey, your browser is showing you a form so you can edit it.
If you don’t like ;edit, there’s a clean alternative:
http://example.com/articles/1.form
With that URL, it’s pretty clear that you’re not doing anything to the article, you’re just getting a form representation of it. Nothing more, nothing less.
When I first read Dave’s article and thought of that naming convention, the ;edit-as-representation-identifier concept seemed too trivial to spend any time on. However it seems like there’s a lot of misunderstanding about what it means. Maybe we should in fact move to an extension like .form to help drive the thinking in the right direction. That’s what RSpec does to get us away from a TDD-as-testing mindset to a TDD-as-design one.
- Of course it doesn’t guarantee anything, but it does if you’re using the web correctly.