> Restlet can support all kinds of things, including the ability to have the
> same ServerResource class provide different subsets of the uniform
> interface depending on the URI.
Can you show an example of this, please?
> I just don't understand *why* you would want to do this. You described two
> kinds of resource (corresponding to two URI patterns, /user/{id} and
> /user), one kind supporting GET, PUT, DELETE and the other kind supporting
> POST. You *can* use the same ServerResource implementation to handle both
> (by overriding default ServerResource behavior), but it's like throwing
> away polymorphism in OO programming and implementing everything in one
> class with switch statements: It doesn't buy you anything, and it will
> confuse people who read your code.
Again, I would like to understand how do I override the default ServerResource
behavior. Not that I am going to rush and do it, but it will contribute to my
understanding of the ServerResource abilities.
> It sounds like you're pushing against the constraints of the REST paradigm,
> which limit you to exposing at most one GET operation per resource. If you
> have both GET-by-name and GET-by-identity operations, you need to have two
> kinds of resource (if you want to be RESTful), which most naturally
> corresponds in Restlet to two ServerResource subclasses.
I disagree. It is a common practice to provide multiple urls to the same
resource. Take for instance, the Jenkins (Hudson) CI server. Given a job MyJob
and 535 being the latest build number, then the same resource, namely the job
build #535 is available using two different urls:
- http://bla-bla/jenkins/job/MyJob/12
- http://bla-bla/jenkins/job/MyJob/lastBuild
How do I implement this in Restlet using a single ServerResource? This
ServerResource class is going to have a single Get() method and it would be my
responsibility to check whether the url is parameterized with an id or it is
the lastBuild permalink. This is a boring boilerplate code. If the native
Restlet API supported strongly typed request handlers, then I would have two
Get methods:
public BuildBean Get(int id) { return GetBuild(id); }
public BuildBean Get(){ return GetLastBuild(); }
(Of course, this example limits me to only one permalink, when in fact there
may be more, like lastFailedBuild, lastSuccessfulBuild, etc ... But, I hope it
conveys my point)
Another real world example are Mercurial changesets. Any changeset has a
universal identity, which is a string, quite a long string, if I may add. But
in addition to this, any changeset has a numeric id, which is unique within the
particular repository clone. Hence we have a resource, which can be accessed
using two unique keys of different types, which is modeled rather easily with
two Get methods:
public ChangesetBean Get(int id) { ... }
public ChangesetBean Get(string hash) { ... }
Both return exactly the same resource.
I do not see how these examples contradict the REST paradigm. If you do -
please explain.
> Huh? This discussion didn't mention JAX-RS until you brought it up. And
> what do you mean by the "native Restlet API"? Your first post in this
> conversation mentions the @Get annotation from Restlet, and it doesn't
> mention the lower-level Restlet API or JAX-RS' @GET annotation.
Why do I mention JAX-RS? Well, I am complaining about being unable to write
strongly typed request handlers and that having parameterless handlers (having
the body parameter does not change the picture much) forces the developer to
write tons of boring boilerplate code. JAX-RS is brought simply because this
specification satisfies my complaints. This discussion has never mentioned
JAX-RS and I would have never mention it had I seen another solution to my
problems. By native Restlet API I mean the API which mandates writing
parameterless request handlers, if the term "native Restlet API" is inadequate,
by all means correct me and I will happily use the right one.
What strikes me the most is that folks seem to be OK with this methodology (of
having parameterless request handlers). For me, it is a major turn off, but I
cannot ignore the fact that Restlet is extremely popular, so I am trying to
figure out how to work with it efficiently. Right now, I do not see it possible
without the JAX-RS extension.
------------------------------------------------------
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2890005
