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