Another bandwagon I haven’t jumped on is REST. It’s amazing how many words you can read about a technical subject without being sure if you’ve actually learned anything or not. But this Dare Obasanjo post made a bit more sense. Apparently in a REST architecture:

1. interaction is client-server
2. communication between client and server is stateless
3. requests [is that a typo? does he mean responses?] are either cacheable, or not, and marked as such.
4. [mumble mumble jargon genitives technobabble]
5. there can be multiple layers (proxies, gateways, etc.) betwen client and server without the client or server having to know or care

That all seems pretty straightforward, and not really deserving of a sweet piece of technical nounage like representational state transfer. Perhaps the devil is in the one point that’s slightly less straightforward than the others? I’ll let you guess which one that is.

No, I’ll just quote Obasanjo directly.

there is a uniform interface between components which allows them to communicate in a standard way but may not be optimized for specific application scenarios. There are four interface constraints:

1. identification of resources;
2. manipulation of resources through representations;
3. self-descriptive messages; and,
4. hypermedia as the engine of application state.

(Emphasis in original; numbered points broken out by yours truly.)

Oh, and he was doing so well! It’s not obvious to me what any of these mean, and it’s even less obvious what they might mean as constraints. “Identification” is not a constraint. “…through representations” might be a constraint, but it seems like a pretty trivial one to me — how, in the client-server system described above, is a client going to manipulate (or even see) any resource except via some representation? I guess “self-descriptive” could be a constraint, though having worked with a number of people who claimed to write self-documenting code, it seems to me to be a constraint loose enough to drive a truck through. I might understand the last one if I knew what “hypermedia” and “engine” were supposed to mean in this context. Then again, I might not.

Luckily for us Obasanjo does go on to address these in more detail. As far as I can tell, they translate to:

1. Give everything a URI.
2. Use well-known data types / formats.
3. Make proper use of protocol headers, error codes, etc.
4. Use links, not cookies.

Okay, I think I’m starting to get it. (1)-(3) lay out a sort of minimalist program for web services, one I think I could get behind, in principle. It certainly sounds more fun than generating SOAP stubs and skeletons. (4) is the interesting one. On the one hand, it follows logically from “stateless” — or would, if all us Java EE developers weren’t used to thinking of state(less|ful)ness as a property of the server. On the other hand, true statelessness is hard for a procedural / OO programmer to wrap your head around.

“This is probably the most controversial and least understood of the architectural constraints set forth in Roy Fielding’s dissertation,” says Obasanjo, and I’m not surprised. Because, Fielding’s cogent arguments against cookies aside… the problem of representing state with URIs looks, to me, a whole lot like the problem of representing state with functions.

Comments closed due to spam.