Panel Urges API Providers To Prioritize Their "Developer Experiences"

Mark Boyd
Mar. 05 2014, 08:00AM EST

ProgrammableWeb’s Editor-in-chief David Berlind moderated a lively panel session at the recent DeveloperWeek conference in San Francisco. The panel included industry thought leaders Jason Harmon from PayPal, Jeremiah Lee Cohick (Fitbit), Alex Salazar (Stormpath), Uri Sarid from MuleSoft (the parent company of ProgrammableWeb) and John Musser, founder of both ProgrammableWeb and API Science. In an hour-long panel on "emergent APIs," panelists covered API design, SDKs versus APIs and the challenge of API versioning. Bonus points: Each shared their number one piece advice for developers in businesses charged with creating their first API.

How important is developer experience?

Berlind stirred the panel with a devil's-advocate approach to designing-in for the developer experience (DX) of an API. "Is DX really necessary?" Berlind asked. After all, developers are problem-solvers who will do what it takes to get things done. Although the panel agreed with Berlind that developers are a resilient, resourceful bunch, they cautioned against taking too many shortcuts in API design.

Sarid urged API designers to take an all-encompassing business approach: “You should think about your customers, and design your [API] product around your customers.... And developers are your customers.”

Harmon agreed with the idea that developers would do what it takes if they needed to access a business’ data via API, but he cautioned that a poor DX would destroy developer loyalty and make it harder for businesses to build an active, evangelized community around their API products: “If developers have to jump through hoops to get to the capabilities unlocked in your API, they are going to send a nasty tweet. It’s customer feedback.”

Musser suggested that new API designers could look at engagement levels on ProgrammableWeb to determine what makes a successful API. (Writer’s note: Keeping up with Adam DuVander’s posts, for example, is a great way to review current industry best practices, because he often writes summary posts about what leaders are doing or trends he has identified from ProgrammableWeb data.)

“If you look at the top APIs on PW, the data was so good that developers were going to use it,” Musser confirmed. “The second group of API popularity was with businesses like Twilio and Stripe, which have created a business by doing a great job at user experience.”

Sarid shared the example of a previous project he had worked on at a company before MuleSoft: "Scraping data from a TV Guide API needed to be done for a business project, but it was such a difficult process that it brought in the whole question of whether the business model would be viable" if the process needed to be repeated regularly, Sarid said.

In this case, he agreed that because the business needed the data (at least once), it would make the API work. However, this was done at the expense of long-term customer loyalty. “The minute someone comes along with a better API that can give access to that sort of data, everyone jumps to that data source. So you are building on a house of cards to choose [not to prioritize the developer experience]," said Sarid.

API business models

Even though the panel consisted of developer evangelists who were comfortable getting their hands dirty with coding and API design issues, panelists were also used to liaising with the business side of their companies. It was a position the panelists encouraged all API developers to take in their business.

“API-first sounds great, but it is a means to an end,” said Salazar. “The business value we are trying to provide happens to be a very developer-centric problem—that is, solving identity authentication. So to deliver that product to our developers, it makes sense in an API.”

Stormpath’s case is interesting and can be unique among businesses looking to create APIs for their end customers. For many established businesses, APIs create new access pathways into a business’ data. But for Stormpath and other API-as-product business models, it is a service component or functionality that is being made available by an API.

“Exposing data is a traditional business approach to creating an API product. Exposing business logic is an API-first product business model,” said Harmon.

APIs vs. SDKs

Harmon described the API strategy discussion that he is leading at PayPal. “We are coming on very strong now with a look at the total vision of our business capabilities and putting together a capability model first: What are the capabilities we really offer? Then we are talking about user interface; that’s the basis of all of our REST API design," he said. "We need to create a quality experience for developers. Our SDKs often tend to be the training wheels to get people used to our APIs. Measuring things like ‘time to first hello world’ (for both external and internal developers) is important. What it boils down to is speed and capability.

“SDKs are a way to get quickly onto a platform. If I buy a car and I know I want to race eventually, I want to buy a car that I can get down to the wires with. The SDK is like the plushy dashboard; the REST API is the race car,” Harmon said.

Meanwhile, in the long run, Salazar sees SDKs as more integral than APIs for developers who want to get up and running quickly. “They tinker with the API to get a feel for the features we offer, but, as soon as they actually want to start to integrate, they are looking for an SDK in the programming language they want. What we are now seeing is that customers want framework integration: It’s not enough to have a Python SDK -- you need a Django framework as well," he said.

“If you are building an API capability into your app or product, SDKs do a lot of the heavy lifting: SDKs can provide caching, for example.”

When looking at the API versus SDK question, both Salazar and Harmon recommended reviewing API analytics to see how developers are using APIs. “Check your API analytics to see what client developers are using—it will open your eyes to what is happening,” said Salazar.

API versioning

The panel unanimously agreed that API versioning is one of the greatest challenges in API design and development.

“The challenge with APIs is that it is very difficult to change anything,” Salazar said. “You need to do some future-scoping to see what API capabilities you may need in one or two years from now. The best way forward is to follow proper REST models: Represent everything as a noun. If you get any type of scale, it will hurt you if you do not."

He added: “Modular design is always faster and cheaper than insular design. As a developer, be wary of insular design; it will slow you down and, as soon as you have a competitive product, you will have a modular competitor coming up behind you who is activating an ecosystem of partners.”

Harmon believes developer engagement from the start can help with some of the challenges with versioning APIs down the track. Managing a good directory of who is using your API enables a provider to communicate change. “If you don’t start early with engaging your developer community—you need to know who they are from day one—you will have great difficulties broadcasting change [if you are retiring an early version of your API].”

Final advice for business developers getting started with an API

Audience members asked the panel to share their top recommendation for developers embarking on API design in their business. Here’s what the panelists shared.

Sarid: “Start with API design, and make sure the market wants that thing.”
Salazar: “Documentation!”
Cohick: “User research will validate your API design.”
Musser: “The business model comes first: How well is your API mapped to your business model?”
Harmon: “Instrumentation: Make sure you can measure how people are using your API and what error codes are being logged. You can’t live without it, and you have no operational where-with-all without it.”

By Mark Boyd. Mark is a freelance writer focusing on how we use technology to connect and interact. He writes regularly about API business models, open data, smart cities, Quantified Self and e-commerce. He can be contacted via e-mail, on Twitter or on Google+.

Mark Boyd is a ProgrammableWeb writer covering breaking news, API business strategies and models, open data, and smart cities. I can be contacted via email, on Twitter, or on Google+.

Comments

Comments(3)

User HTML

  • Allowed HTML tags: <a> <em> <strong> <cite> <blockquote> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Lines and paragraphs break automatically.
  • Web page addresses and e-mail addresses turn into links automatically.

Thanks for the really interesting write-up.
This API vs SDK issue is a really tricky one. I believe it probably cannot be answered in a standard way but depends heavily on an API providers context. SDKs certainly lower the entry barrier for developers and if your developers are a fairly homogeneous group, it makes absolute sense to provide SDKs. If that is not the case then SDK maintenance for several platforms could become a nightmare.

Thanks for adding to the conversation both Denis and Manfred. We will be unpacking the SDK vs API question in future blog posts on <em>ProgrammableWeb</em> over the next few months. It is a constant developer dilemma -- both amongst API providers/designers and API consumers. There is some growth in dynamic APIs and orchestration layers that are sophisticated enough that the API can connect and work with multiple devices, SDK versions and the like. I will look into this a bit more and provide some followup details in a future article. I am sure that it is something that the developer community that attends <a href="http://api-craft.org/" rel="nofollow">API Craft</a>will no doubt be discussing this year.

I could share a real story about API vs SDK issue. Some time ago we were tasked to review an API that was already publicly released. It was a REST API, the documentation was very good, but the API was so low-level and complex that a basic use case ("Hello world" literally) took about 2-3 hours to accomplish. The main reason of the difficulties, from my point of view, was extremely "low-levelness" of the API + difficulties to make those specific API calls for the specific platform. Anyway, since the API was already released, it was almost impossible to change the design without introducing some breaking changes. So, after presenting the results of our review to the API devs, they decided to create SDKs/wrappers to hide the complex functionality and to provide a clear and simple interface through the SDKs. In that case SDKs really help. Actually, there are two levels of the functionality: 1. SDK for the most common use cases and 2. API for advanced tasks. It would be interesting to know the ROI thought. As Manfred said, supporting SDKs for many platforms could be a not easy task.