Is REST === ROA?

I’ve had this feeling of unease around REST for awhile, and I’m coming to the conclusion that there’s a central disconnect in the abstraction we’re using for the RESTful model.

REST is “Representational State Transfer”, so at least nominally it centers on the ideas of “state” and “representation”. But the state in a RESTful communication is tied to the representation, and only indirectly to the underlying resource.

That is, if I request a data resource using a GET, I get data back that represents the state of something in the system. But the data, whether it’s XML or JSON or tab-delimited lines, is just a convenient way to represent the data, rather than a pure serialization of the underlying database rows or whatnot.

For example, I might throw some things into the representation, like calculated values, or maybe hyperlinks, that don’t exist in the underlying object. Or I might leave some stuff out that the client has no business seeing.

What makes it worse is that the “pure” data objects in my system might have several representations. Or else I might be able to GET resources that combine several underlying data objects. Or a lot of underlying data objects. Worse, the GET might return a representation of a calculated result, for which there’s no persistent underlying data object at all.

There is this idea, that I am fond of, that RESTful services are the same as Resource-oriented Architecture. That if you expose a service, follow all the REST rules, and diligently follow the GET PUT POST DELETE model, then you have an ROA system.

But trying to claim that REST is ROA puts us in a hard place when we look at questions like, “What about searches?” Search is one of those hard problems in the REST world, because it clearly belongs there, and yet there isn’t a persistent underlying resource that maps to a search result.

Ultimately, I think it comes down to a shared misconception that RESTful communications are Resource-oriented. But I don’t think that’s right — they are Representation-oriented.

I’m still kicking the idea around, but in the end I think we’re going to have to get rid of the idea that REST is ROA. They are very compatible, but still not the same.

There are already standards around for communicating data structure as well as data, but I think we’re going to have to rely on those to provide our ROA. REST is a useful model for shaping communications to remote services, but there’s still a big disconnect with what we’d really expect from a true ROA.

EDIT: I just did a little more reading, and it sounds like it boils down to: “resource” doesn’t have a single definition. Lots of specs mean different things when they say “resource”. So that is an area of emerging clarity. In essence, saying you’re doing “ROA design” is like saying you’re doing “?OA design”. I guess I’m too practical, so it’s easy for me to discount the “resource” part and focus on the practical “representation” side. 😉



Filed under REST

4 responses to “Is REST === ROA?

  1. Pingback: This Week in #REST – Volume 31 (Dec 13 2010 – Jan 8 2011) « This week in REST

  2. Resources is ‘information’ addressable by a URI. REST is Resource-Oriented, in that Resources are it’s primary artifact, but not all Resource-Oriented solutions are REST. REST has defined constraints to achieve specific properties open client-centric network system.

    Resource-Orientation, to my knowledge, doesn’t have a specific definition other than the association with its artifact. This provides a great deal of flexibility in solution design. Most Resource-Oriented solutions are going to loosely follow REST constraints.

    For our part, we willfully violate REST tenets and use our own server-side method to calculate a system response on behalf of the Client. We know we give up direct addressability by client, bookmarking, serendipity, etc. – but what we get is a very lightweight Resource-Oriented Framework for information-intensive composite applications.

    My perception is that REST folks see schism rather than kinship when looking at Resource-Oriented solutions, which is unfortunate.

    • roby2358

      I think the schisms arise because the REST adherents are working to fend off the GET/POST methodology that the Web was pretty much built on. Unfortunately, some other practices get wrapped up in the terrible “Is it RESTful?” question along the way.

      Really I think your statment, “REST has defined constraints to achieve specific properties open client-centric network system” is a concise statment of what I tried to say in my post 😉

      Ultimately, these standards are emerging, and eventually we’ll have some acronym that comfortably encompases it all. For now, I feel it’s useful for me to try to “get inside” the different approaches, so I’m using my methodology deliberately and not accidently, like I usually do.

      • Thanks for responding.

        I wholeheartedly agree – intentional architecture, whether REST or not, is one of the great take aways from Fielding.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s