Tag Archives: language

Representation … Resource … and …?

OK I’m trying to get my brain wrapped around the terminology in REST. I think the important thing to bear in mind that REST is a client-server, client-pull-message (or client-message-push) architecture. So it’s about how to identify and move information initiated by a client.

The main things that REST boils down to are:

  • Identifier: some arbitrary string which points at an instance of data from an abstract class of data
  • Representation: just some way to bundle up information for transmission
  • Resource: a conceptual idea of some information you want to either get, or put in place
  • Static resource: a resource that is backed by some data that’s going to stick around for a while, so you expect to get the same information back for multiple retrievals over time, more or less
  • Dynamic resource: a resource that is more ephemeral, like a calculation done on the fly, or an aggregation of other data that might be changing rapidly
  • …? : behind the resource, there will be some data storage, or processing, that results in a bundle of data we can call a resource and roll up into a representation and point to with an identifier

I see the last bit called an “entity” frequently, but really the REST architecture definitions, including Roy Fielding’s, mostly stop at the resource  level and leave the rest to our imagination.

Personally, my main stumbling block is at the use of the term “resource”. I think of that word as something static, or even worse, a specific instance that I can put my hands on. So when I say, “a resource”, I usually think “the blue mouse in the top drawer of my desk.” In common usage, that blue mouse is a resource. It’s something I can use. But in the REST world, the Resource is “computer mouse”, and the Identifier adds “/desk/drawer?which=top”. So what I normally think of “a resource” in common usage is really a Resource + Identifier in REST parlance.

In the OO world, an abstract class is a Resource, and an instance is Resource + Identifier. More or less.

I think one of the main reasons for all the blurriness is that what we call REST is really a collision of several worlds:

1) The REST architecture itself, as laid out by Roy Fielding. Which is really more about ways to string together client-server systems in a uniform way, granting interoperability and scalability at the expense of efficiency.

2) The HTTP protocol, which is the primary protocol people use to implement REST. It’s not at all correct to say “REST is HTTP”, but if you are doing the REST thing, and putting it on top of HTTP, then REST commands you, “Use HTTP strictly! Don’t use your own personalized variation of HTTP!”

A personalized variation of HTTP is essentially what 99% of the industry uses today.

After all, despite it’s pretensions, the software industry enjoys freedom from the tyranny of rational thought.

3) The ROA, or resource-oriented architecture crowd, which tends to take the basic terminology of REST and wrap it around a design based heavily on “static resources” or “nouns”. I say noun-based and not object-based, because the strict ROA guys require hyperlinks, but don’t allow intermixed data and methods like you’d see in OO.

4) All the personal preferences, biases, superstitions, agendas and personality disorders of everyone who’s involved with developing software for the Internets. Which, taken together, somehow fails to oblitherate points 1-3. Most of the time.

Based on the conversations I’ve seen where I work, the primary religious conflict is between the static resource and dynamic resource crowd. Let’s face it, the Internets were built not just on a series of tubes, but on the GET/POST verbs. Chopping RPC out of REST flies in the face of what Fielding was trying to do in his paper — to capture what made the Internets work.

For example, some guys in my shop who were brave enough to dive into the Flex realm have been horrified to discover that Flex doesn’t support even the basic set of functionality required to implement a static-resource-over-strict-HTTP design. It basically just supports the GET/POST model, and no more. For some reason, the Flash guys thought that was all they needed.

All that said, I fall heavily on the “noun” side of that religious war, if only because it’s more challenging and fun.

So the upshot is, from my readings, I think that REST is a very open-ended idea that almost every web developer has been using for the past 10 years anyway, just because that’s the way browsers and web servers work. Now we’re getting strict about the HTTP protocol — which is a really good thing — and raising the awareness of the power and simplicity of noun-based design. Which is also a good thing.

But I’m going to try to keep the terminology straight, because I think the core ideas of REST are worth keeping in mind, and it’s important to keep the terminology clear in discussion.

Not that I’m good at that, especially where it doesn’t help my argument.



Filed under computer architecture, REST

Functional REST

On the drive home a while back, I was thinking about the REST model, which is resource-oriented. Everything in the system is a resource. The pointers are all references to resources. The allowed operations are variations on CRUD, and no more. Well, not much more, if you’re doing it right.

So the next obvious thing is to make functions first-class objects, er… resources, as well.

I haven’t thought it all the way through, but I think that offers some interesting possibilities.

  • The resources that a client uses GET PUT DELETE on are, in fact, stateless functions.
  • The stateless nature of functional programming fits perfectly with the stateless nature of REST services.
  • Someone who has the right permissions could PUT their own function definition into the system, and then POST data to invoke it.
  • The functional language could reference other functions, naming them by URI.
  • Functions in the system could take advantage of all the meta-patterns that functional programming provides, like mapping, reducing, filtering, composing, joining, etc. I bet you could even generate lambda functions.
  • URIs are long, so you’d probably want some sort of aliasing feature 😉
  • The input for POSTing could be a combination of the usual resource representation, like JSON, and URI references to other resources.
  • Monitoring would be hell. I think you’d want to have some sort of CPU meter and an automated kill switch, depending on how much leeway you wanted to give your users.
  • The access control model would be interesting, since a wide range of data resources might be involved.

Interestingly, this is kind of along the lines of a system I put together about a year ago, where I used Java reflection to map URIs and POST bodies to a Command-pattern API that we have internally. At the time, I didn’t really really think about it as a “functional” (well, it was functional in the sense that it worked and people were really happy with it). I was just mapping URIs to the Command objects in the API using Java reflection. I didn’t think too hard about the big picture, so I don’t think it counts.

It’s kind of an interesting idea. I did a search, and haven’t seen any other references to “functional REST”, but I’ll keep my eyes open. With all the functional programming wonks running around, it’s just a matter of time before someone puts a system like that together. …Someone probably has already.


Filed under REST

Language is Moot

I found a cool online book on bitbucket.org, and when poking through some of the chapters, I found an interesting excerpt in one of them


On the Squeak mail list in 1998, Alan Kay had this to say:

…Smalltalk is not only NOT its syntax or the class library, it is not even about classes. I’m sorry that I long ago coined the term “objects” for this topic because it gets many people to focus on the lesser idea.

The big idea is “messaging” — that is what the kernal of Smalltalk/Squeak is all about… The key in making great and growable systems is much more to design how its modules communicate rather than what their internal properties and behaviors should be. Think of the internet — to live, it (a) has to allow many different kinds of ideas and realizations that are beyond any single standard and (b) to allow varying degrees of safe interoperability between these ideas.

If you focus on just messaging — and realize that a good metasystem can late bind the various 2nd level architectures used in objects — then much of the language-, UI-, and OS based discussions on this thread are really quite moot.

Leave a comment

Filed under computer architecture