Not quite, the permalink would the url of a page you "stick" to, not the url of the service that powers that page.
> From: petr.jurak_at_gmail.com
> To: users_at_jersey.java.net
> Date: Thu, 5 May 2011 21:00:44 +0200
> 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
>