I think you shouldn't worry about the version numbers at all for following reasons:
1. Either you'll improve existing code so if there was a bug or performance issue, update to new version should automatically fix the issue. 2. Or add new routes can be added without worry. E.g. I'm using JavaMonitor Rest Services and I've built an iPhone application. If you fix something in the service and introduce a new version, I've to fix my iPhone client. But if you fixed some bug and client call and service response structure remains the same, the service fix will automatically fix my iPhone client. If you add new features or change a structure, simply add new routes so existing clients won't break and in the release notes mentioned that the new routes have fixed this or that and have this or that change in the response. I think every service should provide an index page with list of available services and what parameters it accepts and expected response. Will be quite useful while building the client. Farrukh On 2011-01-08, at 7:50 PM, Pascal Robert wrote: > I will start building some REST services (bridge between clients and > CalDAV/Exchange servers) and I was wondering about what to do with services > versioning, AKA what to do when changes are required in the services that can > impact older clients. I want to avoid doing such changes, but we all know > that sometimes, it's a necessity. > > So, after doing a couple of Google search, it look like most people use one > of those ways to work with versioning of REST services. > > - Using a version number in the URLs (aka : /ra/v1/tasks) > - Using the Accept header and use a media type specific to the application > (vnd.myapp.service-v1, vnd.myapp.service-v2) > - Using a custom HTTP header (X-MYAPP-VERSION: v1) > > The last one (custom HTTP header) doesn't seem to be used by a lot of people, > and for the other twos, it look like it's a culture wars, some says that > putting API versions in the URL makes it look that it's a different > resources, others says that using media types is a PITA for nothing. > > Any opinions on this? Anyone tried to version their ERRest-backed services? > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Webobjects-dev mailing list ([email protected]) > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/webobjects-dev/farrukh.ijaz%40fuegodigitalmedia.com > > This email sent to [email protected]
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
