Re: [rest-discuss] Objects at REST...

["Andrzej Jan Taramina" <andrzej@chaeron.com>]

Steve:

Brillant analysis of what I was trying to get at.  Thanks!

> No, I don't agree with equating them. Their similarities are far less than
> there differences. 

I absolutely agree with this.

> First, REST is about representations and stateless protocols for state 
> transitions. So, for the latter, one would have to fundamentally assume 
> Software Transacted Memory (STM) for all objects, but only up to its membrane
> (i.e. the boundary where internal objects tare not directly exposed). 

To clarify your comment, which I agree with, REST might work reasonably well 
for stateless "objects", like EJB Session Beans for instance.  Where the risk 
lies is that the un-discerning unwashed masses (and their PHM slavedrivers) 
will apply the approach to key business objects which were never designed to 
be stateless.  Down that path lies madness. ;-)

> Second, I know I am in the minority here, but pretty URIs are irrelevant. It's
> something for humans to enjoy. If you have them, great! If not, it's
> irrelevant. Sub-structure, relationships are discovered by message exchange
> and never constructed unless told so by the source representation. So, if you
> have http://foo/resource/sub-resource orhttp://foo/resource/
> andhttp://foo/sub-resource is simply not relevant. 

I'm a bit ambivalent on this comment.  Machine to machine, pretty URI's are 
quite irrelevant.  But when it comes to testing machine to machine 
integrations, debugging and the like, which is conducted by meatware, pretty 
URI's can provide some real productivity and value. It's also very difficult 
to predict how an interface might be re-purposed in the future (new mashups, 
new integrations, new applications, etc.), and again, having pretty URI's can 
help those developers to understand and utilize the URI's and representations 
more quickly/easily.  So why not make 'em pretty....doesn't take much more 
effort and can have some decent payback.

> Third, not all objects are equal. The first wave of object-oriented 
> programming was about class inheritance (class inheritance). The second wave
> was about matching interfaces at the instance level only (prototype
> inheritance). Notice how both have to do with thegeneralizationprocess, not
> the actual instances. In REST, we care about the instances and not the things
> that created them. You can use structured programming, object- oriented
> programming, or one-offs to implement your web-services and web- applications.
> Again, the methodology irrelevant, only the properties of the running system
> are. 

So what you are saying is that the exposed interfaces and common lingua 
franca between such services/apps is what is key.  I subscribe to that, 
especially in the integration space.


> Lastly, and most importantly, is the guaranteed decoupling of the resource's
> state from its representation.  This means that you have made the major leap
> already where the information consumer's view of the world may absolutely not
> be related to the producer's view of the world.  And certainly, this is where
> REST has made it's mark in web application design.  In object-oriented design,
> programmers fundamentally think about sharing objects.  This last point is
> relevant, because it ties back into the first point.  

And we run into the classic problems that attend object serialization!  
Better to design a representation from scratch that avoids those issues.

> Creating membranes
> -- think of them as encapsulation at the instance level instead of the class
> level -- in object-oriented systems is hard because of the high-degree of
> interconnectedness of objects.  On the other and, in REST, you build
> everything as membranes since you never directly manipulate the bits, only
> their representations.  Hence, this problem is solved at the root.  This is
> important, because it's hard problem to solve in object-oriented systems. 

Nicely put, Steve!

> In short, mapping concepts from object-oriented programming to REST will
> make people think about it in the wrong way and therefore do more harm than
> good, in my humble opinion. 

And was the root of the unease I have with Rick's approach.  

Andrzej Jan Taramina
Chaeron Corporation: Enterprise System Solutions
http://www.chaeron.com