From: Marc Hadley <Marc.Hadley_at_Sun.COM>
Date: Fri, 13 Apr 2007 12:31:22 -0400

> Also, +1 on Jan's suggestion to incorporate the notion of container
> resources, although I have some sympathy if someone questions
> whether this is implied strongly enough in the HTTP spec.

Paul and I did experiment with this idea a little but ran into some
practical problems. We were trying to write abstract base classes for
APP such that a developer could just implement the abstract methods
in a couple of subclasses and have a working APP-enabled service.
Paradoxically, the problem we ran into was that whilst an annotation-
based approach is very flexible, trying to define an application
contract based on classes/interfaces loses that flexibility. E.g. you
could define a container class like this:

public abstract class Container<C, I> {

   public abstract C get();

   public abstract I postItem(I item);
}

and an Atom specific subclass like this:

@ConsumeMime("application/atom+xml")
@ProduceMime("application/atom+xml")
public abstract class AtomFeed extends Container<Feed, Entry> {

   public abstract Feed getFeed();

   public abstract Entry postEntry(Entry entry);
}

An application class could then be written like:

@UriTemplate("/feeds/{feedid}")
public class MyAtomFeed extends AtomFeed {

   public Feed getFeed() {...}

   public Entry postEntry(Entry entry) {...}
}

But with this approach there's no way to use the @UriParam annotation
to get the feedid, you have to dip into the low level API. You could
adjust the method signatures of the Container class but then you end
up prejudging the URI structure, e.g. what happens if I need more
than one URI parameter in my URI template.

Its a knotty problem that we never came to a satisfactory solution to.

Marc.

---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.