users@jersey.java.net

[Jersey] Re: Restful Service Versioning

From: Rob - <skyscrapper666_at_hotmail.com>
Date: Fri, 6 May 2011 17:08:45 +1030

Do you care? In any case... Do you actually permalink the URL for a service powering the resource your are after or the resource itself???


Date: Thu, 5 May 2011 20:21:26 -0500
From: rds6235_at_gmail.com
To: users_at_jersey.java.net
Subject: [Jersey] Re: Restful Service Versioning

What is a "page"? And if you have a permalink that is somehow above and beyond versioning, what version is it?

On Thu, May 5, 2011 at 8:03 PM, Rob - <skyscrapper666_at_hotmail.com> wrote:






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

>