On 08/31/2012 10:50 PM, Lili Nader
Usually, if the change is additive (meaning we add new attributes or resources) we do not increment the version number and the new information is still available in the old version.
ok. so that would mean that changes that remove properties or change
semantics would get pushed to API 1.1, right?
I hope that there wont be too many of them. I'm currently thinking
about how the openshift-java-client would support 1.0 and 1.1 (to be
able to talk to a 1.0 server at X and 1.1 server at Y) and I
currently dont see any golden hammer that would get fail-safe for
all kind of changes. The most fail-safe approach would be to drop
the strictly typed objects and replace them by loosely typed
maps/collections. To be honest I'd love to avoid this if possible.
Solved in a less fail-safe but still strictly typed manner would be
to provide distinct object hierarchies for the different protocol
versions. I'd love if you had some thoughts/hints to share.
Googling for advices on evolution of RESTful API's I found a guide
I'd hope that we could stick to something equivalent, since this
would make my live much easier. Would you agree/disagree?
I did a search through the code and it seems the only difference between 1.0 and 1.1 is the information returned for a cartridge. The major difference seems to be the properties attribute returned in 1.0 versus 1.1.
Thanks for looking this up!
You're referring to
----- Original Message -----
From: "André Dietisheim" <adietish redhat com>
To: Dev ex-elb1-prod-1847871222 us-east-1 elb amazonaws com, "Lili Nader" <lnader redhat com>, "Krishna Raman" <kraman redhat com>
Cc: "Xavier Coulon" <xcoulon redhat com>
Sent: Friday, August 31, 2012 12:56:11 AM
Subject: How to know what's supported in REST service 1.1?
Is there any way for us to find out what differs in 1.1 vs. 1.0 protocol
for the REST service?