See for example the first google hit in the search I suggested:
http://barelyenough.org/blog/2008/05/versioning-rest-web-services/
2011/5/5 Petr Jurák <petr.jurak_at_gmail.com>
> Well, I've meant using e.g. Accept http header to get appropriate content.
> Petr
>
> -----Original Message-----
> From: Suchitha Koneru (sukoneru) [mailto:sukoneru_at_cisco.com]
> Sent: Thursday, May 05, 2011 9:05 PM
> To: users_at_jersey.java.net
> Subject: [Jersey] Re: Restful Service Versioning
>
> Thanks all of you for the pointers.
>
> Petr,
> Can you please elaborate on what "content negotiation" means in this
> context
>
> Thank you,
> Suchitha
>
> -----Original Message-----
> From: Petr Jurák [mailto:petr.jurak_at_gmail.com]
> Sent: Thursday, May 05, 2011 12:01 PM
> To: users_at_jersey.java.net
> Subject: [Jersey] Re: Restful Service Versioning
>
> IMHO version in URI isn't good idea. This will mess up resources and break
> permalinks. I think it's better to use content negotiation and some custom
> media types.
> Therefore I agree with Ryan.
>
> Regards,
> Petr
>
> -----Original Message-----
> From: Ryan [mailto:zzantozz_at_gmail.com]
> Sent: Thursday, May 05, 2011 6:47 PM
> To: users_at_jersey.java.net
> Subject: [Jersey] Re: Restful Service Versioning
>
> This is a widely- and hotly-debated topic that has been done over many
> times
> before. Check http://www.google.com/search?q=rest+versioning. A strong
> argument against embedding versions in the URI is that it implies v1 and v2
> of some thing are in fact two different things because they have two
> different identifiers (URIs).
>
> On Thu, May 05, 2011 at 10:59:27AM -0400, Gary Moore wrote:
> > +1 to versions in the URL. You can also use a request header value.
> >
> > Using the URL scheme with Jersey, it would be as easy as writing a new
> > Resource class(s) with new endpoints. For example:
> >
> > @Path("/v1/myresource")
> > public class MyResource
> >
> > @Path("/v2/myresource")
> > public class MyResourceV2
> >
> > You can use url re-write rules so that legacy clients (that didn't
> > have the version in the URL) would get routed to v1.
> >
> > Another solution, if you didn't want to proliferate your resource
> > classes, could be:
> >
> > @Path("/{apiVersion}/myresource")
> > public class MyResource
> >
> > Then your methods could interpret the apiVerison and act accordingly.
> >
> > Gary
> >
> > On Wed, May 4, 2011 at 9:12 PM, Jason Erickson
> > <jason_at_jasonerickson.com>
> wrote:
> > > From a URL perspective, I have seen the version included in the
> > > path. For
> > > example: http://domain.com/ws/v1/people and
> > > http://domain.com/ws/v2/people would point to two versions of the API.
> > > However, that is just a small part of the problem. I would also be
> > > very interested in best practices used by others who are using
> > > Jersey and JAXB to implement the versioning scheme described above
> > > (or any other version scheme that people use to solve this problem).
> > > On May 4, 2011, at 5:36 PM, "Suchitha Koneru (sukoneru)"
> > > <sukoneru_at_cisco.com> wrote:
> > >
> > > Hello Jersey Users,
> > >
> > >
> > >
> > > What are the best practices for versioning of Restful services.
> > > Our application will have multiple versions of Restful services
> > > being published over a period of time. I could not find a
> > > standardized approach which W3C recommends for versioning of services.
> > >
> > >
> > >
> > > Thanks,
> > >
> > > Suchitha
> >
> >
> >
> > --
> > Gary Moore
> > http://www.gmoore.net
>
>
>