[
https://issues.apache.org/jira/browse/WINK-107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12732992#action_12732992
]
Bryant Luk edited comment on WINK-107 at 7/19/09 4:32 AM:
----------------------------------------------------------
{quote}I'm not quite familiar with the selectVariant() functionality and the
use-case, but as I understand from javadoc: the selected variant must be from
the variants list. Therefore, the user may rely on == operation, which won't be
true if new Variant() is used.{quote}
Yes, the variant will come from the list, so == should work.
When I was talking about doing new Variant() I was more talking about inside
the resource method itself. For instance:
{code}
@POST
public void doSomething(@Context HttpHeaders headers, String something) {
String contentEncoding = //
headers.getRequestHeader("Content-Encoding").get(0) with check for null
Variant requestVariant = new Variant(headers.getMediaType(),
headers.getLanguage(), contentEncoding);
// now you know what String is suppose to represent
}
{code}
That would be much more straightforward IMO than calling a
Request.selectVariant() that finds the best possible request representation.
I think a better use case would be:
{code}
@GET
@Produces("application/xml", "application/json", "text/plain")
public Response doSomething(@Context Request request) {
// if this method supported all 3 media types and French and English
List<Variant> possibleResponseVariants =
Variant.mediaTypes(MediaType.APPLICATION_JSON_TYPE,
MediaType.APPLICATION_XML_TYPE,
MediaType.TEXT_PLAIN_TYPE).languages(Locale.FRENCH, Locale.ENGLISH)
.add().build();
Variant bestPossibleResponse =
request.selectVariant(possibleResponseVariants);
// now based on bestPossibleResponse.getMediaType() and other getters choose
the best representation to return as the response
if(bestPossibleResponse.getMediaType().equals(MediaType.APPLICATION_JSON_TYPE))
{
// return
Response.entity(json).type(MediaType.APPLICATION_JSON_TYPE).build();
}
// etc.
}
{code}
Browsing around http://httpd.apache.org/docs/2.0/content-negotiation.html - the
"Apache Negotation Algorithm" on that page seems to be the best algorithm to
follow unless someone finds a clearer RFC.
was (Author: bluk):
{quote}I'm not quite familiar with the selectVariant() functionality and
the use-case, but as I understand from javadoc: the selected variant must be
from the variants list. Therefore, the user may rely on == operation, which
won't be true if new Variant() is used.{quote}
Yes, the variant will come from the list, so == should work.
When I was talking about doing new Variant() I was more talking about inside
the resource method itself. For instance:
{code}
@GET
public void doSomething(@Context HttpHeaders headers) {
String contentEncoding = //
headers.getRequestHeader("Content-Encoding").get(0) with check for null
Variant requestVariant = new Variant(headers.getMediaType(),
headers.getLanguage(), contentEncoding);
}
{code}
That would be much more straightforward IMO than calling a
Request.selectVariant() that finds the best possible request representation.
I think a better use case would be:
{code}
@GET
@Produces("application/xml", "application/json", "text/plain")
public Response doSomething(@Context Request request) {
// if this method supported all 3 media types and French and English
List<Variant> possibleResponseVariants =
Variant.mediaTypes(MediaType.APPLICATION_JSON_TYPE,
MediaType.APPLICATION_XML_TYPE,
MediaType.TEXT_PLAIN_TYPE).languages(Locale.FRENCH, Locale.ENGLISH)
.add().build();
Variant bestPossibleResponse = request.selectVariant(variants);
// now based on bestPossibleResponse.getMediaType() and other getters choose
the best representation to return as the response
if(bestPossibleResponse.getMediaType().equals(MediaType.APPLICATION_JSON_TYPE))
{
// return
Response.entity(json).type(MediaType.APPLICATION_JSON_TYPE).build();
}
// etc.
}
{code}
Browsing around http://httpd.apache.org/docs/2.0/content-negotiation.html - the
"Apache Negotation Algorithm" on that page seems to be the best algorithm to
follow unless someone finds a clearer RFC.
> Need to agree on what Request.selectVariant() should do
> -------------------------------------------------------
>
> Key: WINK-107
> URL: https://issues.apache.org/jira/browse/WINK-107
> Project: Wink
> Issue Type: Bug
> Components: Server
> Affects Versions: 0.1
> Reporter: Bryant Luk
> Assignee: Bryant Luk
>
> I would like to discuss what Request.selectVariant() is suppose to do and use
> this issue as a fix if necessary. Originally, the IBM implementation of
> Request.selectVariant() was implemented very similar to the way that Wink
> currently has now. However, I later changed the implementation to be "a big
> mess".
> For the current implementation in SVN, I don't understand why you would
> iterate over the List<Variant> when you could just easily create the Request
> version of the variant (Content-Type, Content-Language, etc.) by doing new
> Variant() and using the HttpHeaders interface to fill in the constructor
> parameters.
> A better use of selectVariant() is to choose the best possible response
> Variant IMO. Also, the method is suppose to modify the Vary header after
> being called according to JavaDoc and when I look at the Vary header in
> specs, it always mentions adding the Accept* headers.
> Basically, I tried implementing a selectVariant() method that would choose
> the best variant based on the incoming request's Accept* headers (given a
> list of possible *response* variants), A somewhat simple use case in my
> variation is that you have a @Produces("*/*") on the method and your output
> can be in XML, plain text with either English or Spanish in the response
> content (so 4 variants would be built and passed into selectVariants). The
> incoming request prefers Spanish and plain text as designated by the
> Accept-Language and Accept header respectively.
> After selectVariant() is called, the application developer can then call
> Variant.getMediaType() to find out which media type is preferred to send back
> and more importantly language and encoding.
> I tried looking at Apache CXF but they return null. Also, discussed this
> with Mike before he left and I think that's why he got all confused with
> Accept* headers. :)
> In short, I was wondering what the use case was for Request.selectVariant()
> would be, and if necessary change this implementation since this would affect
> application code before 0.1 goes out.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
