REST as Domain Model

There’s an interesting article here:


http://www.jroller.com/rickard/entry/the_domain_model_as_rest

I’m always interested in people talking about anti-patterns, because humans are so powerfully oriented towards recognizable patterns, they easily fall prey to patterns that don’t serve them well.

In this case, I agree with the basic premise of his article, that there’s a big mis-match between the idea of a published domain model, and the representation served by a RESTful service. It can’t be one-to-one. As he mentions, any hyperlinks added to the object on the way out don’t fit the source data. Also, there is often information in the domain model that we don’t want to expose.

It’s easy to make the bold, macho statement that we will expose Everything! But there are laws on the books for that sort of thing.

(Innuendo aside, try designing a user login and registration system with the Expose Everything methodology. You’ll become sad very fast.)

The main complaint I have with the article is that he then falls into the “REST as RPC” problem, embedding verbs or actions into URIs. I personally think some form of that is going to become inevitable, but as yet the REST community is sticking with the “nouns only” rhetoric.

There is a further anti-pattern that I see which is the “REST as CRUD” anti-pattern. I talk to really bright guys who insist on shoehorning CRUD — create, retrieve, update, and delete — into the REST verbs. Even after they hit the practical realization that it just doesn’t fit, they still insist on making that equivalence. With some critical exceptions, of course.

It seems to me that the big barrier to entering the REST world is that you have to take the principles of REST as their own thing. REST isn’t *just* for publishing an internal data model. It’s not *just* for exposing raw data storage. In some cases, those patterns apply, but REST is really a lot more, and less, than either of those.

Rather, REST is a strategy for designing remote service APIs that boil things down to some simple principles. It’s a good strategy, or style, but it’s limited to what happens at the border between things.

The trouble seems to start when people get the border confused with what’s inside. And shaking the habits of how we think is just hard.

1 Comment

Filed under computer architecture, opinionizing, REST

One response to “REST as Domain Model

  1. Pingback: Scott Banwart's Blog » Blog Archive » Distributed Weekly 85

Leave a comment