RESTXQ and parameters in the media-type

Hello, I would like to know if the parameters in the media-type should be in the "produces" annotation or elsewhere. Because I can't get it to work with the media-type of an atom feed member. %rest:produces("application/atom+xml;type=entry") The valid syntax can be found in rfc2616 section 3.7 Media Types: http://tools.ietf.org/html/rfc2616#section-3.7 In the RESTXQ wiki page, we can see the media type of an atome feed %rest:produces("application/atom+xml") But I did not found anything about using a parameter in the media type. Thanks.

Hi Philippe,

the RESTXQ spec. or/and our implementation may need to be extended to support subtypes. Reg. your use case.. Do you depend on the support of subtypes, or would it "just" make life easier? Christian

Philippe,

thanks for the details, and: yes, of course I wanted to refer to the media type's parameters. -- I guess you are busy enough with many other issues, but if you find some free time and want to speed up things, you are invited to have a look into our RESTXQ implementation: https://github.com/BaseXdb/basex-api/tree/master/src/main/java/org/basex/http/restxq Best, Christian

Hi Christian,

Aren't subtypes already supported by RESTXQ? I was talking about the parameters of a media type which is the "type=entry" part in the following media type: application/atom+xml;type=entry I've used such parameters in "produces" as in %rest:produces("application/atom+xml;type=entry") I could omit this annotation but what I like in specifying this annotations is that it will not map to media types that would not be understood such as "application/foo" for that URI. I would like to find a generic way of returning a 406 (not acceptable) eventually. That is what rfc2616 suggest: If an Accept header field is present, and if the server cannot send a response which is acceptable according to the combined Accept field value, then the server SHOULD send a 406 (not acceptable) response. But what I understand from rfc2046 is that the server should map according to media type and subtype and not from parameters: MIME implementations must also ignore any parameters whose names they do not recognize. So I guess we could still use the full media type string along with the parameters but that they (the parameters) are ignored by RESTXQ for the mapping of the request to a function. Then in the response function we could access the parameters array to figure out the additional constraints applicable by the presence or not of some parameters. -- Philippe