[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Objects at REST...

• From: "Peter Hunsberger" <peter.hunsberger@g...>
• To: andrzej@c...
• Date: Wed, 12 Mar 2008 09:29:55 -0500

On Wed, Mar 12, 2008 at 7:28 AM, Andrzej Jan Taramina
<andrzej@c...> wrote:
> Rick Jeliffe just posted a blog entry entitled "Objects at REST" on xml.com,
>  found here:
>
>    http://tinyurl.com/2oqrzm
>
>  where he proposes exposing objects using REST.
>
>  I've always had a problem with this approach.  Though it seems like a good
>  and easy thing to do (urlrewritefilter, which Rick mentions, does rock and
>  can help clean up REST URIs nicely), but there is typically an impedence
>  mismatch between objects and resources that is very difficult to bridge while
>  staying true to REST principles:
>
>  1) Objects tend to be much more fine-grained than is appropriate for
>  distributed systems access.  I would have thought that we would have learned
>  this from the ill-fated EJB Entity beans fiasco of a number of years ago.

Although I think you're correct in your "EJB Entity bean fiasco"
observation I'm not so sure that an analogy applies directly to
exposure of front end objects.  In particular, I 'd expect that if you
choose your object abstractions carefully Rick's approach might make
some sense.

>  2) WIth objects, the tendancy will always be towards using a RPC appoach,
>  which is not in keeping with REST principles.  Objects tend to have little
>  "data" and many methods, while resources (in the REST sense) are the reverse,
>  with much data and few methods. Mapping between the two concepts will be
>  problematic.

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

>  3) It may be rare to find a clean mapping between lower level objects and
>  resources, without using an intermediary facade layer to bridge the two
>  levels of abstraction, especially since most OO-based systems were not
>  designed to be exposed as resources using REST.

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.

>  I'm curious what others think of this notion of exposg objects using REST?

I've come to the conclusion that the more generalized the system the
more abstract the objects.  As such, you have two possible extremes
with such an approach:

1) A system that has very specific objects and methods and is of such
limited utility that a generalized approach such as automated mapping
from URIs to objects would be overkill;

2) A system that is so generalized that the objects require extensive
parametrization in order to achieve anything, so that as a result any
automated mapping is going to require extensive additional metadata.
At this point you might as well as generate the URIs directly from the
metadata since the objects themselves aren't really adding any value.

Somewhere in between that  spectrum I'm sure are a bunch of systems
that would benefit from the approach that Rick suggests, but
personally I either do quick RAD knock offs for solutions heading
towards the first end of the spectrum or otherwise head towards the
second end of the spectrum for larger Enterprise type solutions.

-- 
Peter Hunsberger

• Follow-Ups:
  • Re: Objects at REST...
    • From: "Andrzej Jan Taramina" <andrzej@c...>

• References:
  • Objects at REST...
    • From: "Andrzej Jan Taramina" <andrzej@c...>