<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">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. <div><br></div><div>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.<div><br><div><div>On Oct 27, 2011, at 10:59 AM, Bryan Taylor wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>On 10/27/2011 08:56 AM, George Reese wrote:<br><br><blockquote type="cite">THE API SHOULD NOT BE SERVING ATOM CONTENT!!!<br></blockquote><br>What!? Atom is a fine way to represent a collection. Especially one that is append only.<br><br><blockquote type="cite">There's a nasty habit within the OpenStack community of trying to boil<br></blockquote><blockquote type="cite">the ocean. And here we are navel gazing over feeds and crap when the API<br></blockquote><blockquote type="cite">can't yet support the most basic of functionality.<br></blockquote><br>What does that have to do with versioning?<br><br><blockquote type="cite">I've worked with just about every damn cloud API out there. I have a<br></blockquote><blockquote type="cite">very solid grasp on how cloud APIs get consumed, what people have done<br></blockquote><blockquote type="cite">right, what people have done wrong, and where we need innovation.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">We need innovation in pushing data to API consumers.<br></blockquote><br>I disagree, but this isn't the thread to debate push vs pull as it has nothing to do with versioning.<br><br><blockquote type="cite">Version and content desired belong in the headers for request and<br></blockquote><blockquote type="cite">response. The imaginary crap you are dealing with a) don't require them<br></blockquote><blockquote type="cite">in a URL unless you are pulling it from the URL bar of a browser, which<br></blockquote><blockquote type="cite">is NOT an API use case and b) doesn't help you deal with the core<br></blockquote><blockquote type="cite">functionality of the API that is now OVER A YEAR BEHIND where it should be.<br></blockquote><br>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.<br><br>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.<br></div></blockquote></div><br><div>
<span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div>--<br>George Reese - Chief Technology Officer, enStratus<br>e: <a href="mailto:george.reese@enstratus.com">george.reese@enstratus.com</a> t: @GeorgeReese p: +1.207.956.0217 f: +1.612.338.5041<br>enStratus: Governance for Public, Private, and Hybrid Clouds - @enStratus - <a href="http://www.enstratus.com/">http://www.enstratus.com</a><br>To schedule a meeting with me: <a href="http://tungle.me/GeorgeReese">http://tungle.me/GeorgeReese</a></div></span>
</div>
<br></div></div></body></html>