RE: Determinism in content negotiation

[Thierry Boileau]

Hello,

well, in your case, the conversion of Blah objects to Representation is taken 
into account by a JSON converter. From the point of view of converters, there 
is not difference between the two annotated methods, because they both return a 
Blah object. And as they are two methods that are able to generate json 
representations, the algorithm choose the first declared one.
As a general rule it's better to put specific methods before the generic ones.
I wonder why the are two distinct methods. Do they generate distinct objects?
I can see a reason to use a specific method when you control the way to 
generate the json representation and don't want to rely on converter. In this 
case, if you remove the JSON converter and change the method so that it returns 
a Representation, the content negotiation happens correctly:
@Get(json)
public Representation retrieve2() {
   //return a JSON Representation according to your own serialisation algorithm.
}

I don't argue to reply plainly to your request, so feel free to ask for more 
details!

Best regards,
Thierry Boileau

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2664862

Determinism in content negotiation

[webpost]

With an HTTP request containing Accept: application/json, the Resource @Get 
method that is being called depends on the order of the functions as below:

Resource1 {
@Get
public Blah retrieve1() {//this gets called}
@Get(json)
public Blah retrieve2() {}
}


Resource2 {
@Get(json)
public Blah retrieve2() {//this gets called}
@Get
public Blah retrieve1() {}
}

Wouldn't it be nice if it preferred the @Get(json) method whenever I ask for 
application/json? 


The reason this is happening is, Variant's properties are used for content 
negotiation, whereas the annotation information is in VariantInfo, which is 
ignored in org.restlet.engine.util.Conneg.scoreVariant(Variant).

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2663692