> 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