<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Aug 26, 2010, at 4:31 PM, Erik Carlin wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; 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; ">Jorge, I know you have some ideas about a binding "framework" that could be<br>used to build bindings in a common manner. Could you please share your<br>ideas with the group?</span></blockquote></div><br><div><br></div><div>Sure,</div><div><br></div><div>We're aiming for consistency with our public APIs so that:</div><div><br></div><div>1) Collections are handled consistently</div><div> a) Pagination works the same across APIs</div><div> b) Filtering works the same way across APIs</div><div>2) URIs are built in the same manner</div><div> a) Versioning is handled the same way</div><div> b) URIs follow a consistent pattern</div><div>3) Error conditions are handled consistently</div><div> a) HTTP error codes are mapped in a consistent manner</div><div> b) Error info is return in the content of the message in the format</div><div>4) Special features should be included in every API and handled consistently</div><div> a) Queryable Rate Limits</div><div> b) Changes-since operations</div><div>5) Authentication/Authorization...</div><div>6) Polling operations and events...</div><div>etc...</div><div><br></div><div>A big plus of standardizing these sort of things is that it helps simplify life when building language bindings. The idea is to build a "framework" that captures, in multiple programming languages (Python, Ruby, .Net, Java, Perl), the things that are going to be consistent between APIs. There are two big plusses to this:</div><div><br></div><div>1) When a new API comes around, we can produce language bindings pretty quickly. We'll need to add code to handle the new entities, and point to a new base endpoint, but that's about it.</div><div>2) We can spend time to add real value to the language binding, and fixes to a language binding for one API can be shared by others.</div><div><br></div><div>Ideally I'd like the language bindings to seem natural and abstract away a lot of the annoying features of the underlying protocol. For example, consuming a collection should look something like this:</div><div><br></div><div><b><font class="Apple-style-span" face="'Courier New'" size="3"><span class="Apple-style-span" style="font-size: 11px;">while (list.hasNext()) {<br> Server s = list.next();<br> println “Found a server: “+s.name;<br>}</span></font></b></div><div><br></div><div>The list handling bits are implemented by the underlying framework. They abstract away the fact that:</div><div><br></div><div>1) The list may be paginated</div><div>2) Multiple HTTP requests may be required</div><div>3) An authentication token may expire mid-way through the iteration and a new token should be obtained</div><div>4) We may be asked to back off for 2 seconds because we've hit a rate limit, </div><div>....and so on.</div><div><br></div><div>Certainly, we should expose features like pagination for programmers that need them, but for the most part I think a large number of developers would love to interact with our APIs without worrying about protocol level details. The framework provides a way to provide this to clients in all our APIs.</div><div><br></div><div>-jOrGe W.</div><div><br></div><div><br></div></body></html>