Version in the URL rocks. It's much more simpler.
> Date: Thu, 5 May 2011 10:59:27 -0400
> From: gary.moore_at_gmail.com
> To: users_at_jersey.java.net
> Subject: [Jersey] Re: Restful Service Versioning
>
> +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