Hello Darin, I can't give you a concrete answer, but wanted to reply. We are also facing this question. We have made our new version yet, but I had been thinking of following the media-type extension strategy as described in this article, as it seemed like a clean way to achieve and should be relatively easier on the consumers of our API I would think. http://www.narwhl.com/2015/03/the-ultimate-solution-to-versioning-rest-apis-content-negotiation/
Which seems like the second approach you mention, using the Accept header. I would be curious to hear how other teams have done it, and in particular if any approach were easier for wink implementations in particular. On Mon, Jan 11, 2016 at 12:12 PM, Darin Amos <[email protected]> wrote: > Hello, > > I have been reviewing the best way to version my ApacheWink API’s for the > last few weeks and I think this is an area where Jax-RS falls a little > short. > > I understand that Apache Wink (Jax-RS) allows two mechanisms to version > API’s that are popular. > - URI path: GET /api/product —> GET /api/product-v2 (or > /api/product/v2 etc…) > - Accept Header: GET /api/product header: > Accept:application/v2+json > > While these both make sense, there are also both a little limiting. I > don’t want to get into a debate about API design, but for me using a query > parameter or a custom header is a better option. > > I am curious if anyone has done versioning with Apache wink with a query > parameter or a custom header in the past. It looks like Apache Wink would > be easy to extend to allow this if the filterDispatchMethods method was > declared as public in the ResourceRegistry. > > Has anyone else tried something like this in the past? > > Thanks > > Darin
