I used a custom Http header, and a Jersey filter to solve this problem. Basically, every incoming request would include a custom version header, and the version of the API they wish to work with. The filter would grab the header value if it's there, and determine if the version of the API server the request came to can service that request, it passes on the request to the resource. If not, it returns an error. The header name can be anything you want. Also, if no header is provided, it is assumed the request will be handled by whatever api is deployed at the server the request went to.
You could use this version value to bounce the request to another capable server in some way as well.. if for example the request goes to a server with an older version of the API, the request could be forwarded to a server that could handle the request, so that you could actually deploy specific versions instead of adding code within the API to handle different versions within a single deployment.
Or, the other way as is similar to some other replies, but by using this header, you can set some request value that each resource, if need be, can determine what version of the api should be handled, then call the appropriate method for the version request to handle the request. To me though, that starts to get messy in the code. I'd rather deploy version 1 of my API, then start on v2 and have it deployed at a separate path. For example, our versions are
http://server.com/api/v1 or /api/v2 and so forth. The combination of the path change and the header can be used to add minor updates to a major version api release if need be.
--- On Thu, 7/7/11, Mathews, Benjamin L <benjamin.mathews_at_optum.com> wrote:
From: Mathews, Benjamin L <benjamin.mathews_at_optum.com>
Subject: [Jersey] Re: Adding versioning support in jersey rest
To: users_at_jersey.java.net
Date: Thursday, July 7, 2011, 7:20 AM
Versioning is not a Jersey specific question. There is plenty of good
(and some not so good) information out there. The best way to do it that
I'm aware of is using vendor specific mime types.
http://barelyenough.org/blog/2008/05/versioning-rest-web-services/
Ben Mathews
-----Original Message-----
From: Jakub Podlesak [mailto:jakub.podlesak_at_oracle.com]
Sent: Thursday, July 07, 2011 7:50 AM
To: users_at_jersey.java.net
Subject: [Jersey] Re: Adding versioning support in jersey rest
On 07/02/2011 07:17 PM, Christopher Currie wrote:
> AFAIK jersey doesn't do request routing on query parameters. A couple
> of options:
>
> 1. If you're flexible with your API, you can make the version number a
> prefix of the path. Then its a simple matter of having a different
> root resource registered for each version of your API.
That would be one option, another one [1] was suggested by Gili and
Conal.
> 2. If your API is not flexible, then you'll have to do the heavy
> lifting. Your root resource(s) methods will have to accept the
> QueryParam argument, check its value, and return the version-specific
> Resource class as a "subresource". Even though this is a bit of an
> abuse of that mechanic, it should achieve the result. But its a lot
> more work than option 1.
Even if your API is not flexible, i would recommend implementing one of
the above mentioned versioning methods and implement a special request
filter [2] in addition in order to allow the special version query
parameter.
The filter needs to lookup the query parameter in the original request
and return the request updated according to the selected versioning
method.
~Jakub
[1]
http://stackoverflow.com/questions/972226/how-to-version-rest-uris/97
5394#975394
[2]
http://jersey.java.net/nonav/apidocs/latest/jersey/com/sun/jersey/spi
/container/ContainerRequestFilter.html
> HTH,
> Christopher
>
>
> On 7/2/11, Umesh Bhatt<umesh_bhatt_at_mindtree.com> wrote:
>> Hi,
>>
>> I want to add version support in my rest web service and want to
>> achieve as mentioned below. Please let me know how to achieve it.
>>
>> In URL I want to add QueryParam version and based on this value want
>> to call correct resource. For this I want to create Http request
>> interceptor to check version info and call appropriate resource.
>> Please let me know how to do this.
>>
>> Thanks,
>> Umesh
>>
>> ________________________________
>>
>> http://www.mindtree.com/email/disclaimer.html
>>
This e-mail, including attachments, may include confidential and/or
proprietary information, and may be used only by the person or entity
to which it is addressed. If the reader of this e-mail is not the intended
recipient or his or her authorized agent, the reader is hereby notified
that any dissemination, distribution or copying of this e-mail is
prohibited. If you have received this e-mail in error, please notify the
sender by replying to this message and delete this e-mail immediately.