> Your proposed refactoring sounds fine. It doesn't move the documentation
> very far away from the code, since the helper class can live in the same
> package as the two ServerResource impls. It might make even more sense to
> move the helper code into a common superclass of both ServerResource impls.
>
> Trying to use one class for two different kinds of resource is a dicey
> proposition even without WadlApplication. It's the Restlet analogue of
> writing a switch statement instead of taking advantage of polymorphism.
Thanks for your feedback. Your comments are fair enough, and I see your point.
What follows is simply an explanation of why this does not make intuitive sense
to me, not an argument that you are wrong. I think your idea of making a common
superclass is probably the way to go.
Restlet may view these as different resources, but they performing similar
actions on the same thing. It seems to me that /object is really just
/object/{objectId} where no objectId is given. For example:
GET object : list all objects
GET object/{objectId} : give me info about one specific object
this would use the same code to either list one or list all.
It is reasonable to create an object in two ways:
POST object : create an object, response should indicate the created object ID
PUT object/{objectId} : create an object with this objectId
I don't think it should be "dicy" to put that in two classes.
Again I see your point, though. Thanks,
bjorn
> --tim
>
>
> On Fri, Feb 10, 2012 at 11:01 AM, Bjorn Roche <bjorn at xowave dot com> wrote:
>
> > hey there,
> >
> > I am trying to use the wadl extensions to document my restlet api, but I'm
> > ending up with some weird results. Here's why:
> >
> > several parts of my api look something like this:
> >
> > /object
> > /object/{objectid}
> >
> > and I use the same serverresource to handle both of them:
> >
> > router.attach( "/object", ObjectResource.class );
> > router.attach( "/object/{objectid}", ObjectResource.class );
> >
> > ObjectResource then handles the calls differently based on the
> > presence/absence of the objectid attribute, but I don't see a way to
> > document such behavior. In the docs, I end up with two entries, one for
> > /object and one for /object/{objectid} that are both identical, and I don't
> > see a way to distinguish in my describe* type calls. Is there some way
> > around this? The only thing I can think of is to refactor my code to
> >
> > ObjectResource -- which handles and documents /object
> > ObjectWithIdResource -- which handles and documents /object/{objectid}
> > ObjectResourceHelper -- which does the work
> >
> > But this goes contrary to keeping the documentation close to the code.
> >
> > Am I missing something?
> >
> > thanks,
> >
> > bjorn
> >
> > ------------------------------------------------------
> >
> > http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2920673
> >
------------------------------------------------------
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2920681
