openstack team mailing list archive

[Bryan Taylor <btaylor@xxxxxxxxxxxxx>]

On 10/27/2011 08:56 AM, George Reese wrote:

> THE API SHOULD NOT BE SERVING ATOM CONTENT!!!

What!? Atom is a fine way to represent a collection. Especially one that 
is append only.

> There's a nasty habit within the OpenStack community of trying to boil
> the ocean. And here we are navel gazing over feeds and crap when the API
> can't yet support the most basic of functionality.

What does that have to do with versioning?

> I've worked with just about every damn cloud API out there. I have a
> very solid grasp on how cloud APIs get consumed, what people have done
> right, what people have done wrong, and where we need innovation.
>
> We need innovation in pushing data to API consumers.

I disagree, but this isn't the thread to debate push vs pull as it has 
nothing to do with versioning.

> Version and content desired belong in the headers for request and
> response. The imaginary crap you are dealing with a) don't require them
> in a URL unless you are pulling it from the URL bar of a browser, which
> is NOT an API use case and b) doesn't help you deal with the core
> functionality of the API that is now OVER A YEAR BEHIND where it should be.

Developers of the API need a way to see the payloads they are developing 
against. They need it to understand what the data looks like to consume 
it in code and they need it to troubleshoot data specific problems. 
Since our data is URI centric, it's quite reasonable for a developer to 
expect to put those URIs in a browser and get something useful.

Whether a particular team has met it's expected roadmap to back it's API 
with a working implementation seems completely unrelated to the best way 
to do versioning to maximize the ability of clients to leverage 
backwards compatible changes.