My API journey is nearing its end. Back in 1999, I first started articulating how user experience (UX) principles could be applied to coding interfaces between objects and systems.
A few of my colleagues at the consulting firm where I was working got it. But it mostly fell on deaf ears. What a difference 15 years makes.
The API Designer/Artist Perspective
The SXSW Interactive Festival in Austin, Texas is in its 21st year now — and with each passing year, its coverage of the API space matures.
Two years ago at SXSW, software designer and programmer Alan Cooper (the godfather of User Centered Design and APIs) and I had a conversation about how designers were missing a big opportunity by not looking at API design as product design.
Last year at the conference, API design and the API economy was covered in several sessions. But I still stood alone as the only one interested in talking about applying both UX design principles and business strategy to the space of APIs.
This year was a glorious surprise for me and other holistic API enthusiasts when it all the conversations about API and design came together.
Jeremiah Cohick Lee, an API engineer at Fitbit, dug deep into advanced API patterns and noted how API designers had seemingly clear choices on driving accessibility and affordance above all else. When I asked him how he balanced API accessibility against other business concerns like performance, he said, "I don't. I always skew towards accessibility."
Last year, I would have shook my head and been disappointed. This year, I get it. Lee is an artist at heart, and explained his motives for using APIs to touch the lives of developers and product consumers in detail. I have come to admire his religious adherence to adoption and accessibility above all else (even if I don't have the same perspective).
Expanding My Perspective
In years past, I believed adoption was the trump card. It's not so much that I now believe this view is incorrect as I believe it is incomplete. I stirred up a lot of attention and conversation a while back when I wrote that UX is not primarily about creating great designs and it doesn't surprise me that the battle between adoption, business models and sustainability continues. It's only in the past year that these ideas have begun to impact API design with Twitter being the biggest example of note.
Before you think that I'm claiming that Lee is thinking small, let me clarify. Lee is thinking bigger than us all. His sights are set on changing the world via API design.
Lee discussed how the power of APIs can usher a new wave of division of labor into the world as APIs do more than share data and content. The real value of APIs is how they share capabilities. Lee closed his talk with asking a simple but evocative question; "What does your API want to be when it grows up?" Lee wants his APIs to be fulcrum that others use to make the world a better place.
The API Business Strategist Perspective
Thor Mitchell, product manager for the Google Plus and Maps APIs at Google, followed Lee brilliantly in a Saturday session titled API Management: The Agony & the Ecstasy. Mitchell spoke about the stages that surround design and articulated the holistic business view of API strategy and management the space has been lacking.
Mitchell spoke about the great paradoxes of API management and gave workable solutions and approaches for each of them:
The Chicken/Egg Paradox of API Marketing - How can you attract developers to your API when you have no developers building cool things on your API? Google's solution to this problem is quite simple: develop a stable of launch partners. Well in advance of a planned API launch, Google starts recruiting partners to build interesting applications on top of the API, given that at least two months are required for a partner to build something that is both functionally compelling and performance optimized, Google front loads their technology implementation to decouple the launch partner's dependencies on Google's fully functional product. As Google approaches the launch date, the launch partners' products magically start appearing.
The Use Case Paradox of API Product Strategy - How do you discourage development of applications you don't want to see? This is where the agony comes in because the business and competitive threats that arise with an open API are not trivial. There are three sets of overlapping threat areas to be managed with a public API — Users, Data and Infrastructure.
- Users - Once a public API is available with mechanisms for establishing connections between people and organizations, someone will take advantage of the API to create the bane of the internet: SPAM.
- Data - Once a public API is available with rich and finite data, "scrapers will come" to harvest the data for their own purposes.
- Capacity - Once a public API is available with some combination of interesting data, functionality and connection points, developers will try to wrap or clone your product offering which, if successful, can put your infrastructure at risk from too heavy a request load.
In essence, these threat areas speak to the idea that your API is the mechanism that developers can use to clone your offering and siphon your audience away from you while simultaneously putting the availability of your services at risk.
The main weapon in managing these threat areas, Mitchell said, is "future proofed terms and conditions." He laid out a full set of topic areas that your terms must cover to give you a first line of defense to discourage the development of products you would rather not see. The individual needs for terms and conditions can vary depending upon what types of services and apps your APIs power but several categories apply almost universally:
- Storage or caching — limit what data clients are allowed to store or cache
- Use out of context or offline — limit the types of contexts that your data and functionality can be used in
- Re-syndication — limit the redistribution of your data and functionality
- Aggregation and derivative works — limit the sorts of products your API users can develop with data
- Forbidden use cases an unsavory lines of business — don't allow any development of applications that could hurt your brand via association
- Use in a commercial context — limit how users can make money off the value they derive from your data and functionality
- Attribution and branding — include guidelines for how content, data and features powered by your API will be presented
Whatever terms you want to set out, make sure that you include a clause that allows for retroactive changes to protect against unforeseen circumstances. The critical point to understand with terms is that they only protect your enterprise if you have the capability to monitor usage and follow up on any violations.
Before you think Mitchell or I are advocating for a big legal enterprise to protect your APIs from abuse, let me explain. Mitchell is fully aware that the use of legal teams to enforce terms against your API users is a last resort that should be skewed away from at almost any cost.
The point of the terms isn't to set your enterprise up for a legal fight. The point of the terms is to discourage developers from engaging in abuse in the first place. A robust API management strategy uses terms combined with active monitoring the usage pattern of APIs, technical rate limits and data throttling to prevent abuse in any of the three threat areas.
The API Team Builder Perspective
The last and most important point in all of these discussions is this. API management is not a short game it's a long one. When you understand this, you can develop a mindset that APIs, just like any product, must have a roadmap and a team capable of seeing and managing each of the above perspectives. Take the time to build the right team and you'll be able to drive both the adoption and sustainability of your product for the long haul.