Le 2011-01-08 à 13:23, Farrukh Ijaz a écrit :

> 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.

Something exists for that:;

  
http://groups.google.com/group/json-schema/web/service-mapping-description-proposal

> 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]

Reply via email to