Open Stack

You know what it has to do with API versioning? It has to do with people proposing bad versioning ideas to support esoteric stuff WHEN THE BASIC STUFF AIN'T THERE YET. 

curl is the appropriate mechanism for manually interacting with an API for development purpose. A browser is a very limited tool for interacting with the HTTP protocol and should not be the boundary of what an API should support.

On Oct 27, 2011, at 10:59 AM, Bryan Taylor wrote:

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

--
George Reese - Chief Technology Officer, enStratus
e: george.reese at enstratus.com    t: @GeorgeReese    p: +1.207.956.0217    f: +1.612.338.5041
enStratus: Governance for Public, Private, and Hybrid Clouds - @enStratus - http://www.enstratus.com
To schedule a meeting with me: http://tungle.me/GeorgeReese

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20111027/b55593e9/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4395 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20111027/b55593e9/attachment.bin>