On Wed, 2011-12-21 at 11:41 -0600, Bryan Taylor wrote:
I would suggest taking at least learning something from libtool. libtool
does this stuff really well if you pay attention to the rules. They are
as follows:
Libtool is not a web service API. I don't see the analogy here. It's a
fine
On 12/20/2011 07:00 PM, Bryan Taylor wrote:
Generally, I like the new versioning proposal and see it as simpler. If
Compute adopts this change and succeeds with it, I'd like to see it
OpenStack wide. Clients shouldn't have to learn several different
versioning schemes.
I agree with this.
Hi Brian,
On Tue, 2011-12-20 at 10:35 -0500, Brian Waldon wrote:
So there obviously isn't one clear way to version a RESTful API. Not
every API is created equal, and therefore doesn't need the same
capabilities in its versioning mechanism. At this point, it is
important to determine what
Thanks for the input, Monty. So the reason I'm suggesting major only is due to
our extensions mechanism. We are using extensions to achieve our incremental,
non-breaking changes rather than using minor versioning. For example, we have a
keypairs extension in the v2 API. We shouldn't go to a
On Tue, 2011-12-20 at 10:35 -0500, Brian Waldon wrote:
So there obviously isn't one clear way to version a RESTful API. Not
every API is created equal, and therefore doesn't need the same
capabilities in its versioning mechanism. At this point, it is
important to determine what
On 12/21/2011 05:02 AM, Monty Taylor wrote:
On 12/20/2011 07:00 PM, Bryan Taylor wrote:
Version APIs for compatability, not release tracking.
I could not agree with this more strongly. Like, really, really, really
strongly.
Strong feelings are not a technical reason.
Clients should
couple
On 12/21/2011 05:56 AM, Mark McLoughlin wrote:
On Tue, 2011-12-20 at 10:35 -0500, Brian Waldon wrote:
- Versioning is important, but I'd prefer us to place more emphasis
on how to design the API such that we can continue to expand the
API in compatible ways for a decent period
Hey guys!
tl;dr -- We need to get API versioning right. I'm proposing we use major
versions in Accept/Content-Type headers.
In order for OpenStack to be successful, we need rock solid APIs. That means
having something stable that fully exposes the necessary functionality of the
underlying
Comments inline:
On Dec 20, 2011, at 11:03 AM, Julien Danjou wrote:
Unsupported Versions
- What do you do when a request is made with an unsupported version?
HTTP 406 ?
We can do that or a 300. I'm proposing 300 so we can be the most helpful, but
that may be overkill. Maybe clients won't
On Tue, Dec 20 2011, Brian Waldon wrote:
So what's the point of not saying that you may not be breaking
compatibility by adding a minor version usage for just new feature for
example?
I should have added that I'm against minor versions in the Compute API due
to our extensions mechanism. I
Generally, I like the new versioning proposal and see it as simpler. If
Compute adopts this change and succeeds with it, I'd like to see it
OpenStack wide. Clients shouldn't have to learn several different
versioning schemes.
My 2 cents on your questions:
On 12/20/2011 09:35 AM, Brian
11 matches
Mail list logo
