Re: [xml-dev] Objects at REST...

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

Peter:

> Again, I think it's a question of what the object abstraction is...

I agree, but am concerned that the OO modellers/architects will just design 
their models the way they always have, and then try to slap the REST layer on 
top, which is going end up a mess.

Sure, if you design your object model up front to be REST-exposed, then you 
won't run into that, but given how little understanding there is of REST in 
the enterprise world, I think it is likely to get quite ugly.  Then the PHM's 
will come into play, reading an article on how good REST is (same as what 
happened with CASE, EJB, SOA, ad nauseum) and how you can just layer an 
automated tool to RESTify existing legacy systems (J2EE classes as legacy 
now, doesn't it? ;-)  ), and then REST gains a bad rep, just like every other 
silver bullet has in the past.

I would prefer not to see that happen, though it may be unavoidable. ;-(

> I think this is the real issue; you can't just go around exposing all
> objects, you are going to have to make some conscious decision on what
> to expose and pick some way of controlling that. Whether this is via a
>  facade, annotations or something as simple as hacking package names
> won't really matter, but the work will still need to be done if such
> an approach is to be successful.

Exactly the point I was trying to make.  I think that this will be rarer than 
many people think, and the temptation to "retrofit" REST onto older OO models 
that lack such conscious design decision making will lead to disaster.

In the world of integration where I play, the back end object models are of 
little interest. What is of keen interest are the common data representations 
that lie in the interfaces between such systems.  And it's been my experience 
that in the longer term, those representations need a lot of design, thought 
and decision-making that is greatly independent of the participating systems.


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