OStatic

A portion of my job at Splunk is helping drive the development of SDKs for our new REST-based APIs. These APIs are served from the integrated web server in the product, which happens to be closed source. While writing software for REST based APIs is fairly straightforward, providing various language-specific SDKs speeds up development time and eliminates common tasks like authentication, searching, and error handling for the end users.

While REST is a fairly common methodology for web site services, running APIs through REST on an installable software product is fairly unusual. Typically, installable software SDKs provide methods which are handled via the operating system and helper programs, like the .NET runtime libraries. Vendors using these types of SDKs only need to compile a single library file for their end users. Supporting these SDKs can be easier than supporting the full set of methods in the product's API.

In comparison, if you take a look at Flickr's web based APIs you'll see an extensive set of methods for accessing the service and pages of documentation supporting each call. They also provide numerous links to SDKs which are written and maintained by external developers, and support most languages. Many of these external projects carry a free software license, a few are licensed under the Creative Commons licenses, and a couple are even closed source. Keep in mind that Flickr itself is closed source.

With Splunk, we realized we'd need to write the first few SDKs if we wanted others to write applications against our new platform. Based on a few customer conversations, and the fact we were launching a new Windows version, we decided our first SDK should be written in Microsoft's .NET. Like most languages, .NET allows for redistributing a compiled dynamically linkable library file (.dll) which can literally be dropped into a developer's project. One could easily argue reasons for the code itself to remain closed source.

However, after a bit of thoughtful consideration, one particular issue stood out like a sore thumb against this approach. Closing the source meant we'd have to maintain and support each and every SDK ourselves, as opposed to simply supporting a single REST API! Worse yet, the more languages we wrote SDKs for the more it would cost us. Closing the source could ultimately prevent us from writing SDKs for less popular languages.

Eventually we realized the necessity of licensing our various SDKs under a free software license. Within the past two months we've posted SDKs on Google Code under the BSD license for .NET, Java, AS3, and Python, and had a couple of users contribute code and suggest changes for PHP. We plan on releasing more SDK code as it becomes available, and will continue to do so under a free software license.

Perhaps other REST-enabled software projects will do the same when faced with a similar choice.

• sdk
• api
• REST
• web server