I also agree that REST could lead to surfacing business meaningful resources, I’ve just seen no coherent discussion on that front and I hate thinking for myself!

Understanding the tradeoffs we’re making is always going to be important – both in terms of an upfront decision to pursue a particular style, and the ongoing critical evaluation of an approach.

As a point in favour of aligning REST and DDD, I’ve found that resource-oriented thinking can often help in surfacing business-meaningful things that might otherwise be neglected or go unnamed. A search result, for example, is a resource as much as it’s the result of an operation: and to a company like Google it’s an important resource – it’s a vehicle for putting revenue-generating ads in front of the user.

As Jim’s pointed out, our approach is more Web-ish than REST-ish: putting good, Web-friendly techniques to work in service of useful business outcomes. What doesn’t necessarily come across in the article is that in our real-world work with clients we’re first and foremost domain- and capability-focused: we’ll quite clearly distinguish between what we’re trying to achieve, and the several ways of providing an appropriate solution (the how). And to that extent we’re very sensitive to the ways in which premature implementation options can obscure or confuse the domain.

And that’s 20 minutes that could have gone into the book

Kind regards

ian

Also on my comments, they were being a bit picky. I can definitely see why you used PUT to update the Order state but I’m just coming at it from a DDD background, and more recently have been trying to combine that style of thinking with SOA/messaging/REST.

In particular what I like about SOA/messaging is that when done well they can end up being business focussed, enhancing and building upon the ubiquitous language that DDD introduces. I’ve yet to read about whether REST should be used in the same way, I can’t think why not but most examples I’ve seen have focussed purely on using REST to solve object distribution problems.

So whilst I can see why using PUT to update an orders state is sensible I do wonder if it robs you of the chance to create an important resource (perhaps OrderUpdateRequest) that might become part of your shared language (perhaps even part of the UL inside the enterprise).

Man that was a long comment, should just wait for the book

The responses to the article have been very encouraging – and challenging – and have prompted us to write again in earnest. We’re picking up on a lot of the commentary and criticism and putting it to good use. We’re hoping to have the bulk of a first draft by the end of the year. Dates nearer the time.

Thanks for the comments here and at InfoQ – very much appreciated.

ian

Definitely seems like its something I’ll be adding to my reading list.

The session was recorded by the JAOO folks – hopefully it’ll pop up on InfoQ sometime in the near future. There was plenty of material I didn’t get the chance to cover, and I’m rejigging the QCon talk to focus on some more real-world implementation issues.

The InfoQ article is a teaser for a forthcoming book – tentatively titled ‘GET /Connected’ – that addresses enterprise development issues from a RESTish point of view. The working example may be a little cute and unrealistic – who’d really automate Starbucks? – but it serves as a platform to tackle a lot of the issues that Jim, Savas and I have encountered in our careers.

Sounds like a really interesting presentation, my main problem with REST is not with the ideas but with the lack of detail about using the ideas to solve the sorts of problems you regularly meet in enteprise development.

Anyway I was wondering if any of the sessions are going to be recorded?