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> 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>
> 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
>>
>