March 27th, 2014

SDK vs API – Round 2

SDK vs APIInspired by a conversation with Kin Lane and Mike Amundsen at last year’s APIdays conference in Paris, I decided to dig deeper into the SDK-vs-API debate.

As I wrote in my last post, I had noticed a pattern of using API SDKs rather than the underlying Web APIs. Let’s quickly define what I mean by SDK. There used to be a time, not so long ago, when “SDK” meant documentation, code samples, build scripts and libraries all bundled together. Today, you find all the former on the Web and usually only the library remains. When I use the term SDK, I mean a programmatic API (e.g. JS, Ruby, PHP, Python) on top of the Web API (usually REST/JSON).

As it happens, my wife gave me a small wearable activity monitor as a Christmas present (I could not possibly think of any reason why I would need that – and the new weight scale in the bathroom must have been pure coincidence). Since the gadget was uploading my stats to a cloud service and this cloud service had an API and my wife gave it to me as a present, I figured I had a perfect excuse to do some coding. My goal was to write a client-side app using JavaScript, pulling my stats from the cloud service via the API (and to keep notes on my experiences).

After registering at the developer portal, I hit my first stumbling block – no client-side JavaScript SDK. The closest I could find was a PHP SDK – which, of course, meant that I had to install PHP (I had not used PHP before) and the framework(s) used by the SDK. I also had to enable a Web server and debug the SDK’s OAuth implementation. That was not quite what I had in mind. Even though I got it running after one day and a half, I ended up being quite frustrated. All that work for a simple Web page displaying the stats for a hardcoded day!

So, I decided to take a different approach and use the SDK provided by Temboo. Again, no client-side Javascript SDK. While I could have used a Node.js SDK instead, I decided to stick with my PHP install and opted for the PHP SDK. From there, the integration was quick and I was up and running within an hour. What I did not like about the SDK was the footprint (it included all possible integrations) and how its abstraction and data presentation leaked into my application code. If I were to build a commercial product using it, I would have to consider the potential stickiness of the SDK. Personally, this did not feel right either. So, I went back to the drawing board and looked at my options.

What had I learned so far? My frame of reference going into the experiment was a client-side app using JavaScript. Yet the only SDKs I had found were written for server-side integration. Since it was the only choice offered to me, I had to invest a significant amount of time finding all the necessary information to get the server-side components and dependencies installed and configured. But even after going through all of this, the experience with either form of SDK left something to be desired.

I had started this exercise thinking that using an SDK was much easier than coding against the Web API – maybe it was time to reassess that assumption.

Looking back at the API documentation, I could not find anything inherently difficult. Looking at the vendor-provided PHP SDK, it dawned on me that the complexity of the client was entirely due to OAuth and the use of XML as payload. This finally gave me the opening I had been looking for. If I could avoid the complexities of OAuth on the client and use JSON as the payload format, I should be able to implement my client-side app with a few lines of JavaScript against the Web API. As a regular guest at Webshell‘s APIdays conference, I was familiar with the company’s OAuth Broker service. It took me a few minutes to get set up, configure the service and download their oauth.js client library. I cut and pasted the sample code into a JavaScript file, consulted the API docs to learn about switching to JSON format and did the API call. I was done in less than five lines of code!

While this experiment is just a single data point, I think it nicely illustrates some of the key lessons in the SDK-vs-API debate. I will attempt to provide a summary from both the API consumer and the API provider perspectives in my next post. I will also be talking about the SDK-vs-API issue in more detail during the upcoming Nordic APIs tour in Stockholm and Copenhagen and at the APIdays conference in Berlin.

January 31st, 2014

Would You Like a Library with That (API)?

LibraryIf you are professionally inclined – like I am – to read all about the business of APIs, you may have gotten the impression that APIs are going to take over everything and bring world peace.

Okay, I’m exaggerating but it is sometimes hard to remember that an API is really just a means to an end. That (business) end can vary. It might mean reaching more or different customers using mobile apps. It might mean integrating with partners. It might also mean giving access to services or data that provide enough value for them to be monetized. But in the end, I’m not using an API for the sake of using an API but because I want to use the services or data served by the API with the least amount of friction to myself because I – as a developer –  have a job to do.

Which brings me to my next point: When was the last time you looked at an API’s documentation and implemented it in a client app? If I need to integrate with an API in my Web app, I simply copy two lines of Javascript from the API provider page and cut and paste my API key into the <your_api_key_here> placeholder. Then I reload my Web app, which loads the Javascript library, which allows me to use the API. Or if I need to integrate with an API in the backend, I look for a pre-build component like a GEM (Ruby-on-Rails) or NPM (node.js) and add it to my loader file. Then I restart the backend, which loads the library, which allows me to use the API. Notice a pattern?

So here I am, using APIs via libraries/SDKs. In fact, I am not even sure when I last implemented a client using API documentation. In terms of priority, I only care if the service offered through the API meets my (business) needs – and then I use its library. And if it doesn’t have one, I might just move right along and look for the next one. (Remember: I have a job to do!)

For most developers out there in the real world, does consuming an API mean consuming an SDK that implements the API via a library? Should we talk about portable library design, efficient library loading (eager or lazy, async or sync) etc? Which platforms do I need to support to maximize my developer reach? What are the tradeoffs between offering (and having to support) a number of libraries versus just the API? Do dynamically-loaded libraries solve the API versioning challenge?

Reading about Evernote’s decision to use the Apache Thrift framework for its client API may help you formulate some potential answers to these questions.

In any case, none of this reduces the importance of providing a well-designed and documented API. Libraries and SDKs simply provide a convenient wrapper around an API and APIs are about removing friction. And client libraries are just another few steps in the march towards frictionless integration. (I still remember fondly the ease with which I was able to create client stubs and OSGI bundles from WSDL during the Web service days.) Nevertheless, we at Layer 7 – as an API Management company – will certainly be looking into how we can provide more support for client libraries in the future.

The preference for using client libraries rather than developing API clients becomes even more pronounced if we look at the Internet of Things.

Almost all the IoT integration vendors I have talked to consider supporting a large amount of client libraries for the myriad different IoT platforms to be one of their key differentiators in the market. Partly, this is driven by the need to optimize client stacks for resource-constrained platforms but it is also driven by the emergence of new binary and publish-subscribe protocols designed to better deal with IoT’s asynchronous communications patterns (see this blog post for a good overview).

While there has been quite some activity around API definition languages lately, I’m not aware of any attempt to provide a formal description language for asynchronous APIs of this type. Maybe this is an area where we will see some new ideas and innovation in the coming months.

In case you’re interested, I’ll be talking more about these trends as part of Layer 7’s upcoming API Academy Summits in London and New York.

November 13th, 2013

QCon San Francisco 2013

QCon 2013This Thursday, I’ll be at QCon San Francisco to lead the RESTful Web APIs tutorial. This will be the second time QCon has hosted the full-day workshop and I’m very much looking forward to it. Most of the material I’ve prepared for this workshop is based on the book of the same name by Leonard Richardson and myself. That book was released in September of this year and we’ve been getting very positive feedback on it.

Participants in the workshop will learn how to design a hypermedia type, how to implement servers that safely and consistently expose business functionality using hypermedia and how to build client applications that understand the hypermedia messages and can interact with servers to create enjoyable user experiences.

Along the way several key principles will be explored, including:

  • Why a hypermedia-based message model is better than a code-based object model
  • How Web servers can expose operations as stateless resources instead of as function calls
  • How client applications can recognize and use hypermedia workflow to create quality user experiences
  • Why the hypermedia approach makes it easier to make small changes on the server without breaking existing client applications

The full-day session will also cover important technical aspects of implementing distributed applications over the Web. We will focus on identifying and managing the boundaries between services in order to increase both security and stability over the lifetime of the service. Attendees will get a chance to use existing services as a guide when creating their own and will even get a chance to introduce changes on the backend to see how their client applications can adapt and continue to function.

I always enjoy these extended workshops because it gives everyone (even myself) a chance to write real-life code for real-life services. I spend quite a bit of my time lecturing and advocating for increased reliance on adaptable distributed systems and it’s a rewarding experience. However, it’s also very energizing to work with people in a hands-on atmosphere where everyone is focused on getting things up and running in a working environment.

Of course, there will be lots of fun in the day, too. We have trivia breaks, I offer some handy prizes and we have plenty of time to relax and get to know each other. Overall, these full-day, hands-on workshops represent one of my favorite ways to spend a day with smart, talented people. And I’m grateful to the folks at QCon who make it all possible.

So, if you’re in San Francisco this Thursday and don’t have anything pressing to do, come on over to QCon and join us. Bring your laptop loaded with your favorite Web coding tools and your thinking cap. We’ve got a place all ready for you.

October 7th, 2013

SDKs or APIs: What’s the Right Choice for Your Developer Community?

SDK or APIWhen creating an application programming interface (API) for a service, one of the key decisions any program or product manager will face is how best to meet the needs of their prime target audience: developers. Faced with this decision, you want to make sure your API is easy to use and doesn’t represent a high barrier to entry for your specific developer audience.

Currently, the typical approach is to design an interface that leverages the most common protocol on the Web today: HTTP. This is often labeled a “RESTful” API (referring to Roy Fielding’s architectural model for the World Wide Web) and offered as a one-size-fits-all (OSFA) model for developers to use when building client applications for a service. But this is not always the best approach.

Properly understanding and implementing a raw HTTP interface may be too complex for some segments of your developer community – some of whom are really only interested in your service and not in spending time to build a killer HTTP application for that service. Additionally, a generic HTTP API might end up compromising key performance aspects of your service in order to work best for a wide range of developer communities (the OSFA problem). Even worse, an HTTP-based API may – in the end – result in unfocused client applications built by developers who know more about HTTP than your service.

What We Learned from SOAP
One of the powerful lessons learned from the SOAP community relates to the value of developer tooling. The SOAP Web Service Definition Language (WSDL) is a complex, difficult-to-read document that contains all the important details on building a compliant client application for a service. And developers have a hard time making sense of the document. To solve this problem, the SOAP community helped promote an “accommodation” for developers –  the “WSDL” button that is available on many code editors. By simply pressing this button and following a few prompts, developers can easily create API facades for servers or consume WSDL documents to build client applications. The WSDL accommodation makes SOAP programming not only easy, it adds to the usability of SOAP interfaces and lowers the bar for developers wanting to use services on the Web.

What We Lost with HTTP CRUD
The rise of JSON-style HTTP CRUD (Create-Read-Update-Delete) programming interfaces meant the loss of the WSDL accommodation. Developers were expected to hand-craft both the server and client interfaces without the aid of a unifying definition document like SOAP’s WSDL. To make up for this loss, server coding environments like Ruby on Rails introduced helper functions (e.g. “rails new”) designed to generate a great deal of the API facade required in order to publish a service on the Web. Developers could use this accommodation to simplify the interface details and allow them to focus on crafting the internal object and business modeling needed to make the service operational.

Client devs needed to create their own accommodations, too. That’s why we have client-side libraries like ember.js, backbone.js, angular.js and others. Like the developers building servers, client developers needed help handling the basic plumbing for HTTP-based applications, so they could focus on their own object models and business logic.

The bad news is, in this HTTP CRUD world, each and every service has its own unique set of URLs, objects (users, products etc.) and actions (approve, remove, edit, apply etc.). And each API looks like a snowflake among hundreds of other unique interfaces. For example, there are more than 500 unique APIs for supporting shopping services. This can raise the bar for developers and lower the usability of HTTP CRUD APIs.

Adapter APIs
Netflix set out to solve the OSFA problem in 2012 by embracing differences in its developer community and creating a set of targeted “adapter APIs”. These are custom interfaces optimized for selected developer communities. For example, Netflix offers one API for its XBox community and a slightly different API for its PS2 community. In fact, each major device has its own custom API.

What’s interesting about the Netflix approach is that the customized interface accommodations live on the server, not the client. In other words, Netflix has taken on the task of optimizing its interfaces for each community and hosting that optimization on its own servers. A client developer will still be using an HTTP API but it will be one tailored to a specific device – a server-side custom library.

Do SDKs Provide the Answer?
Another way to provide solid accommodations to your HTTP developers is to create software developer kits (SDKs) for your service. Essentially, SDKs provide the same accommodation that WSDL-generated client code does for SOAP interfaces. The good news is that well-designed and executed SDKs can lower the bar for developers and increase service usability.

Recently, Evernote announced that it was taking the SDK approach. One reason for this was Evernote’s decision to use the Apache Thrift message model. The Thrift approach serializes messages using a custom binary format and then ships them across the network using one of a handful of transport protocols (including direct TCP/IP). This is pretty low-level stuff and can easily intimidate some client developers – raising the barrier to entry for Evernote’s API – and this is where creating an SDK is a handy approach. Evernote has committed to building a wide range of language-specific SDKs that clients can download, install and use in their own code. This accommodation lowers the bar when using the Thrift model.

The bad news is that creating SDKs is often a recurring additional expense for your services team. Unlike the WSDL standard, which makes it possible to generate code for a wide range of programming languages from a single published definition file, SDKs usually need to be hand-built for each target programming environment. And selecting target programming languages can turn into a slippery slope. Which languages are most used by your current API consumers? What if the most-used language represents only 30% of your target audience? How many SDKs do you need to build and maintain before you reach a significant portion of your developer community?

The maintenance of SDKs can be substantial, too. How often do you release updates? Fix bugs? Provide new features? Each release can mean added cost to your developer community as they need to open up their own code, integrate the new SDK, run tests and finally re-release their apps to their own target communities. Unless carefully done, this can result in added churn and expense all around – including deployment and download costs for end users. And that can raise the barrier to entry and lower usability.

So What’s a PM to do?
When you start to think about the notion of creating accommodations for target audiences, you have a new metric for assessing the usability and value of your service interface. If you can design an API that is easy for your target audience to use, then you (and your developers) win. If your API is too complex for your audience or relies on a less-used technology, you likely need to include more direct accommodations for your developers.

In some cases, the audience will know how to use SOAP interfaces and will benefit from you offering a WSDL as their accommodation. In other cases, the target audience won’t want/need a SOAP interface and a well-crafted HTTP API (or possibly a set of targeted adapter APIs) will be the right choice. Finally, some target developers will want/need an SDK to handle the protocol details and allow them to focus on their own business logic.

In fact, sometimes the best bet is to offer more than just one of these options in order to reach all your target audiences. Your enterprise partners may prefer a SOAP interface, your mobile devs may prefer a well-design HTTP CRUD API and your business and marketing team may prefer an SDK that exposes only the parts of your service they need to use.

You Own the Interface
The key point in all this is that you own the interface. You can cast your service in many different ways, aimed at several different audiences. You don’t need to stick with a OSFA approach and you don’t have to rule out major technology sectors like SOAP just because a portion of your audience prefers one interface style over another.

By focusing on your target audience and learning their skills and preferences, you can identify key metrics that can drive the selection of the right mix of API styles and accommodations that will help you meet your goals for API reach and usability.

August 20th, 2013

APIs & Hackathons Solve the Innovator’s Dilemma

HackathonEach and every large enterprise began as a brand-new venture created by a few co-founders. The team was small, nimble and innovative enough to carve out a market leadership position through execution and differentiation. As the company grew from a few co-founders to 500 employees, 5,000 employees or 50,000 employees, its pace of delivering innovation slowed. Large companies such as Apple, Intuit and Facebook have continued to prove that this innovator’s dilemma is avoidable. For the rest of the Fortune 1000 – companies that don’t necessarily have access to the Silicon Valley magic – the trend in recent years has been to launch “innovation labs”.

One of the earliest examples of this was Bell Labs at Lucent, with many other enterprises now following suit, such as:

The question is: How will a small team within a large enterprise drive a cultural shift towards innovation and not get stifled by the old guard, which is simply stuck in old habits and processes? The solutions these innovation labs are bringing back to top executives almost invariably involve APIs and hackathons.

The first step is unlocking data via APIs. When a team of innovators at a large company is trying to achieve something disruptive and market-changing, the team members will need access to data from across the company. If they cannot get access, they will be delayed, get demoralized and often just give up and move on. When a company centralizes its APIs across all backend systems, it enables employees, partners and even external developers to build and innovate.

The companies with innovation labs mentioned above have also set up robust API platforms to enable innovation. Some APIs are only available to employees, some to partner companies and others are open to all software developers. The key concept is that they have removed the deadbolt locks on their data and replaced them with APIs that intelligently free those resources, auto-provisioning access based on who, how and what access is needed.

Opening up APIs enables innovation culture, increasing the pace of product design, creation and execution. Once these technology enablers are in place, enterprises can run internal and external hackathons to make developers aware of and inspired by what is now possible. These fast-paced competitions set goals to take creative ideas and turn them into prototypes or minimum viable products.

Hackathons are designed to help developers quickly try out new ideas and get instant feedback. This is similar to the iterative product development methodology described by Eric Reis in his book Lean Startup.  Some enterprises call it the migration from a linear process such as “waterfall” to more agile “scrum” or “customer-driven development” processes. Similarly, “DevOps” has been used to describe increased collaboration and communication between software development teams and IT operation teams.

This is how smart enterprises now solve the innovator’s dilemma. Product lines are reinvigorated and employees are inspired to be more entrepreneurial and productive.  Customers are getting products that take advantage of new technologies. Enablement through APIs alongside action through hackathons solves the dilemma and seeds continuous and disruptive innovation.