Two quick thoughts on this -
1) Wouldn't a @PreMatching request filter be able to match before the @Path
chooses a method?
2) In the past we solved this by fronting the Jersey services with a load
balancer that would look at the version header and route the request to an
appropriate cluster depending on major version. Downside is we had to run
multiple servers supporting multiple versions concurrently, but the upside
was that they were sandboxed and didn't have conflicts with methods or JAR
dependencies, etc.
Of course, not everyone has control over their environment to take such an
approach.
On Wed, Apr 6, 2016 at 9:06 AM, 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
>>
>