Say we have:
Accept: x-mycompany.sometype; version=1
While you are right that the version is not strictly part of the
content-type, it considered a parameter of the Accept header and as such
servers are *required* to take it into consideration. See "accept-ext"
at
https://tools.ietf.org/html/rfc7231#section-5.3.2
I believe it is a bug for @Consumes to match exclusively based on the
content-type, ignoring Accept parameters because doing so violates the
HTTP specification.
Gili
On 2016-04-14 10:32 PM, Raúl Guerrero Deschamps wrote:
> Cowwoc,
>
> For the MIME type versioning, you're using it incorrectly, for adding
> the version in the MIME type, you have to define something like
> "vnd.mycompany.sometype.v1+json" and not the ; version=1 thing you mention
>
> Jersey, guys, what's your take on using something like
> @Header("version", "1.0") and such like I mentioned? or should we
> standardise it even more and use @Version("1.0") and Jersey will
> handle the header "version: ${version}" by itself?
>
> Any thoughts?
>
>
>
>
> 2016-04-06 8:27 GMT-05:00 cowwoc <cowwoc_at_bbs.darktech.org
> <mailto:cowwoc_at_bbs.darktech.org>>:
>
> Based on memory, this does not help. When I tried implementing
> this, I used a content-type of "vnd.mycompany.sometype+json;
> version=1" and @Path happily ignored this and chose a class/method
> without looking at @Consumes at all.
>
> Gili
>
>
> On 2016-04-06 9:25 AM, Mark Thornton wrote:
>> You could use a filter to modify the request before matching
>> takes place. I don't know exactly what changes are possible, but
>> it seems likely that a filter could change the media type based
>> on some other header (such as x-version).
>>
>> Mark
>>
>> On 6 April 2016 at 14:06, Gili T. <cowwoc_at_bbs.darktech.org
>> <mailto:cowwoc_at_bbs.darktech.org>> wrote:
>>
>> I'm also interested in this. Last I heard it wasn't possible
>> because @Path chooses a class or method without first
>> examining the headers. I believe this is a very important
>> use-case.
>>
>> Gili
>>
>>
>> On Wed, Apr 6, 2016, 03:34 Raúl Guerrero Deschamps
>> <raul_at_jimi.com.mx <mailto:raul_at_jimi.com.mx>> wrote:
>>
>> Hi all,
>>
>> After researching API versioning with Jersey a bit, the
>> only way I see this happening is through modifying the
>> Accept header and use a special MIME type, and then if
>> the MIME type ends with +xml or +json it's smart enough
>> to understand what serializer to use.
>>
>> Now, what if, because of client restrictions, I can't
>> handle custom MIME types and such, and instead I'd like
>> to use another recommended versioning pattern which would
>> be adding a header to the HTTP request called version,
>> and place the version number there.
>>
>> That way I could do something like
>>
>> @GET("/myObj")
>> @Consumes(MediaType.APPLICATION_JSON)
>> @Header("version", "1.0")
>> public JsonResponse myV1method() {}
>>
>> @GET("myObj")
>> @Consumes(MediaType.APPLICATION_JSON)
>> @Header("version", "2.0")
>> public JsonResponse myV2method() {}
>>
>>
>> Currently, how could I choose which jersey annotated java
>> method to use depending on what the version header value is?
>>
>> Thanks,
>>
>> Raul
>>
>>
>
>