I’m not sure how I missed this post by Jacob Kaplan-Moss, where he’s throwing the kind of REST question out there that has, in the past kept me thinking for hours:
It seems like URIs like /people/{my-uid}/photos and /people/{my-uid}/photos/{photo-id} are more “pure.” But now that’s weird because only one single user ever has access to a given URI (e.g only user #7 gets to access the entire space under /people/7). And the information in the URI is redundant with the information in the Authorization header.
http://www.jacobian.org/writing/rest-wankery-question/
Then things get really interesting in the comments, with links to two great posts (which I also missed):
The last constraint is incredibly simple, but nobody actually does it. It’s named Hypertext As The Engine Of Application State. I still haven’t decided how to pronounce the acronym, I always try to say “Hate ee ohs,” which sounds like a breakfast cereal. Anyway, let’s break this down. We’re using Hypertext, fine, that makes sense. But what’s it mean to be an engine? And application state?
…
Now, when I said ‘nobody’ does this, what I meant was ‘for APIs.’ This is exactly how the Web works. Think about it. You start off on the homepage. That’s the only URL you have to know. From there, a bunch of links point you towards each state that you can reach from there. People would consider it ludicrous if they had to remember a dozen URLs to navigate a website, so why do we expect the consumers of our APIs to do so as well?
Finally, comes an elegant, much more RESTful solution to the API version dilemma:
You can simply define a new media type – sayapplication/vnd.mycompany.myapp-v2+xml – and associate new multi-email format with it. Clients can then request whichever format they want. Older clients don’t know the new media type so they get served the older single email format.
…
Newer clients do know the new media type so they can have access to the new functionality.
All three of these posts/discussions are worth reading, but if you only read one, read Steve Klabnik’s HATEOAS post.
There was a brief mention at the web framework battle royale at sxsw (twitter: #frameworkbattleroyale ) about Java and Enterprise environments and I was reminded of an old peeve of mine: the old enterprise vs. “cool” webby frameworks battle. I don’t want to jump into either the battle or the definition of “enterprise.” For the purposes of this post I’m simply going to define “enterprise” as “acceptable to institutions that only use software described as enterprise.” Realistically, we’re really just talking about Java and .net based platforms and frameworks vs. everything else 
Which brings us to what has always my been my pet peeve about this debate – Rails, Django, Plone, CodeIgniter, etc. – can implement a just a few features and become much more acceptable to these institutions. What are these organizations concerned with? Mostly, it’s compliance, oversight, accountability and, where applicable, adherence to things like PII and PCI.
I will also acknowledge that my thinking probably applies most to Django, since it’s what I know best and I think Python has the least steep hill to climb as a language (vs. PHP or Ruby).
So, what are these steps? To my mind there three things I see as going a long way towards acceptance:
- Content version control These organizations need document history. How many changes has a piece of content (text,html,image, whatever) gone through? Who made the changes, and when? I now include django-reversion in all our Django projects. It’s not my ideal solution, but it goes a long way and continues to get better.
- Object-level permissions out of the box I’m obviously picking on DJango in particular here and there has been a ton of discussion on this topic on the Django mailing lists. Usually the discussion goes something like “write on your own specific to your domain” or “write it and submit it for inclusion”. Fair enough, but that doesn’t change the fact that organizations, especially publicly held companies, really need read/write level object control over their content. Happily, the Washington Times has taken this on this task. Hopefully this project grows and continues to be supported and maybe even eventually can be included in core Django.
- Integration with existing authentication systems. Django has a great authentication framework. It would be even greater if there were some included batteries for things like Kerberos, which you can roll on your own, but it’s not the easiest thing to integrate with if you are unfamiliar.
Implementing these, or similar features in these frameworks would go a long way to getting a foot in the door at bigger organizations. These features would give internal employee stealth advocates (and trust me, they DO exist) some ammo.
Thoughts?