+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