On 12/2/11 3:40 PM, "Mark Kharitonov" <[email protected]> wrote:
>> 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
Two different resources here chief.
Richardson and Ruby state in RESTful Web Services:
Fetching releases/1.0.3.tar.gz might give you the exact same bytestream as
fetching releases/latest.tar.gz, but they¹re different resources because
they represent different things: ³version 1.0.3² and ³the latest version.²
>
>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.
Both return exactly the same *representation*. Doesn¹t make them both the
same resource because they are defined differently. I'll admit it's a
unique case since it would *always* return the same exact representation
but it's a slippery slide when we start saying that two distinct
definitions should be treated as the same resource in some cases but not
others.
>
>
>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=289
>0005
This message and any included attachments are intended only for the addressee.
The information contained in this message is confidential and may constitute
proprietary or non-public information under international, federal, or state
laws. Unauthorized forwarding, printing, copying, distribution, or use of such
information is strictly prohibited and may be unlawful. If you are not the
addressee, please promptly delete this message and notify the sender of the
delivery error by e-mail.
------------------------------------------------------
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2890226
