In REST you want to represent the state so that you can transfer it over the network (yeah, duh). In many forms of programming we often work almost exclusively with objects. Since the state of an object is encapsulated by behaviour it can feel like trying to thread a needle with oven mitts on, “dear object, tell me what you are so that I may better represent you!”

“In an object-based system you can only poke around with a process of 20 questions, hoping that there isn’t some hidden truth that you are unaware of. For instance, talking to a proxy that is almost exactly like the original object, but with some small replacement. Of course internally a server can be peculiarly coupled as well, with relationships between the resources that aren’t explicit or obvious. But at least the faces it projects are fully formed.”

Ha! Twenty questions is a good analogy. Objects can act according to Heisenberg’s uncertainty principle, whereby the act of observing an object changes the object itself. This can be mitigated if you do not treat all objects as conceptually equal. If you have a category of objects whose only purpose is to describe the outward face of another object - including a description of state of the object it describes, then you don’t need to play 20 questions with an object to get a sense of an objects outward face. COM and zope.interface/zope.schema provide such things, but then these are only loose promises of what they think the state of an object is. If your object is a proxy object or has other comlexities then when it comes time to extract state it may not be what you expect.

In these ways of thinking we say interface and implementation. A description of behaviour (interface) and the many possibilities of that behaviour (implementation). There are interesting parallels between this and resources and documents. A state (document) and the many possibilities of that state over time (resource).

Infinite behviour mutliplied by infinite state and the mind is pleasantly boggled … :)

I liked the way you started with late binding.

The fact is, the resource model (eg. web) gives up on late-binding, gives up on polymorphism (there’s no ambiguity about what’s at the end of the URL), and doesn’t really encapsulate behaviour much at all.

That turns out to be OK.

But does it, in fact, turn out to be OK because the web as we understand it simply doesn’t have much behaviour? And so ReST is sufficient to keep it under-control?

Or does it turn out to be OK because, in fact, the extra complexity of managing the indirection needed to give you later-binding makes it impossible to scale? And so programming in the largest large means giving up on hopes of polymorphism altogether … and so living with the redundancy?

Unfortunately you don’t know what the side effects will be - a controller you call might start sending undesirable HTTP headers such as content-length. Also it would be nice, if the call would be rather more than just a method-call; acting like an HTTP client, calling a server so, for example, caching headers can be employed. So perhaps it would be nice to unify fetching a remote resource with fetching one “internally” from memory.

Meanwhile, given a URI for a resource and it’s value (the document), HTTP provides mechanisms for comparing the value you currently have the source you got it from, from modification time to direct comparison via something checksum-like (E-Tags). In most programming languages, when you receive a copy of some variable, you first don’t really have a way to know it’s source and comparisons of values may be difficult and expensive.

Perhaps those are problems that would be interesting to solve at a language level?

buddies do: [ :buddy | buddy sendMessage: myMessage]

note the colon on the first buddy, the period is actually optional

Probably more correct to say that HTTP doesn’t have a way of signalling immutability; REST doesn’t add anything like that to the equation anyway.

This has come up before, on some other blog thread, because there are some fairly clear use-cases for it. The most obvious one I’ve run into is pre-packaged versions of huge JS libraries (dojo, yui), which, at least in production, you could certainly treat as immutable by using a version number in the URL itself (presumably a directory name).

The mapping between what you describe and Ian’s description of REST would seem to be “view -> uri, (view,state) -> (uri,tick)”.

Ian:

Really good stuff.

The pair (uri,tick) can also be represented as object/document, at a uri. Immutable and reference-able resource.

“You can pass around a reference value (a URI), but this is like calling a function with a pointer argument.”

URIs are unlike pointers in that they don’t refer to the same “memory address” (call-by-value, your point), modifications are not necessarily symmetric. For immutable resources, you can ignore the distinction, but signalling a reference’s immutability isn’t something I’ve seen REST try to handle. (Caching with etag/if-not-modified does allow you to grossly detect when immutability becomes non-operative.)

URIs are like pointers in that we can perform some key operations without dereferencing a given uri. Relational join, index/hash lookup; metadata. Microformats, RDF, LinkedData are all focused around expanding the pool of data you know about things you may only have heard of, not yet seen or touched. In immutable/by-value, this property is perhaps associated with lazy evaluation.

On the distinction between document and object models, inheritance is something to consider (or say, polymorphism, to stick with your intro’s avoidance of classes). Date and Darwen in Third Manifesto make a solid argument that an (object model with object-ids) cannot support an (inheritance model with generalization/specialization-by-constraint). It would be interesting to see if the differences between URIs and objectIDs/pointers remove that limitation.

Speaking of document-oriented systems, I think that monads could make for some very interesting applications.

In a document-oriented system (say an interactive web-app) written in a language like Haskell (where state is explicitly isolated), state (which would be contained in a set of monads) could be sent to the client with each response. The state could be something like a continuation.

In this sense, one would have a continuation-based system (like Seaside), but instead of the state residing on the server, it resides with the client. So all documents (in the web-app) can remain immutable.

Researchers at Cornell have developed a stateless network stack based on this idea. It’s called “Trickles” (http://www.cs.cornell.edu/~ashieh/trickles/protocol.php).

This system will probably be impractical if the client state requires a lot of storage space. Perhaps a way around this problem is a hybrid approach where some state is sent to the client and where new documents are created on the server (using something like PUT) to represent the rest of the client state.

But this is pretty much back to the Seaside model (although given my lack of knowledge of the inner workings of Seaside, I don’t know whether client state can be reified as a set of documents).

Consider MFC document-view architecture also, the lines are blurred somewhat between objects and documents as you describe: there is the undo/redo history (state changes) and the view provides a complete snapshot of state at any one time. However, the document is undeniably an MFC object. I suppose the paradigm is dependent on whether you’re a user or a developer, whereas in REST architectures it’s the same…

My immediate though in response to this, is that svn (or any other version control system), addresses this issue exactly. You can get a resource, as it is currently (HEAD), or you can retrieve a particular revision (URI+time).

(Btw. you comment system doesn’t format as markdown, even though it says so)