5 APIStrat Takeaways for Building Your API Strategy

The API Strategy and Practice Conference, popularly known as APIStrat, is a conference focused on the API economy.

This year marked the seventh anniversary of the conference and brought experts from across the world to discuss their experiences, thoughts, and ideas on what’s happening in the API industry in 2016. The conference took place in Boston, November 3rd - 4th. Here are some top takeaways to help you build a successful API strategy for your organization.

1. APIs Provide Value When Treated Right

APIs must be treated like any other product, meaning that time and effort need to be invested in them to make them successful. There’s still a mindset that prevails in a lot of organizations about how much value, both tangible and intangible, an API can procure for a company.

Understanding that the value of the API can only be obtained if it’s treated like any other product is crucial for success. This means that API teams should provide a great product experience for their APIs, market and raise awareness about its capabilities, and support the users who consume their API services. Treating APIs like products automatically places an emphasis on quality, which is where testing solutions (including functional, performance, and security), like those in the Ready! API testing framework, can help organizations provide a dependable and secure experience to their consumers.

“Every software service has the product as its foundation, so start by engineering a great product experience.” – Phil Leggetter ( @leggetter)

2. APIs Are Going Mainstream

As more and more companies add APIs to their product portfolio, it becomes increasingly important to explain APIs to non-technical people, be it sales personnel or the general marketer. Explaining to these audiences becomes easier if you follow the right approach. Start with identifying the value proposition your API will solve for your customers and move from there, increasing in technical depth as you see fit.

Description formats like the Swagger Specification make it easier for non-technical folks to start designing and architecting their APIs, and with human-friendly data modeling languages like MSON, we can see more people involved in building APIs, not just engineers.

“How do you explain your APIs? You talk about the common denominator of your API that anyone, regardless of technical background, can relate to, the real world impact of using that API.” – Andrew Seward ( @MrAndrew)

3. Build With the Developer in Mind

Many of the sessions at APIStrat focused on the experience of the end users of your API. An API’s target end consumers include developers, and as such, API publishers need to optimize the developer experience (DX) which they are presenting to their consumers. Good documentation, diverse SDKs, and great response feedback are just some of the ways API publishers can help more users adopt their API. Developing APIs with the end consumer in mind is the first step to building a great API which caters to the needs of the masses.

Getting early feedback from your developers helps as well, which can be facilitated with SmartBear products like SwaggerHub, that allows multiple collaborators and pilot consumers to work and view APIs with the right access control. The importance of documentation can be further validated by the massive adoption of the Swagger UI, an interactive documentation of REST-based APIs that allows developers to operate against various API endpoints without any code, making their life easier.

Developer marketing is crucial as well, as it means giving enough information to get the end developers aware of the value proposition of the API and helping them get them started with using your services quickly.

“Developer experience is the entire end engineer experience with the API, not just endpoints.” – Matt Bernier ( @mbernier)

4. Give Your API Strategy Time

Companies like Facebook, Stripe, Twilio, and Ziggeo have all proved that APIs can be great assets to companies. However, adopting an API strategy is still relatively new, and various companies struggle with understanding what their value is.

One of the biggest reasons why APIs are shut down is because top executives still fail to see the value that can be obtained from an API. One common statement is that APIs don’t have a direct correlation with revenue. However, what these organizations should realize is that with time and effort, APIs lead to a lot of tangible value to a company, including revenue, returned business, and increased partnerships. Either way, it’s crucial to remember that updating or deprecating an API is a huge deal, leads to investment in resources, and amounts to a loss in trust with your end developers. Only do so if there’s a very strong reason.

“Remember, if an API works and sells, don’t change it incessantly, because this would mean developer time, and that’s expensive.” – Steve Rice ( @_steverice)

5. Adapt to Microservices the Right Way

There seems to be a lot of buzz around microservices and the advantages this approach brings to a company’s infrastructure. Microservices places huge demands on the network, and in many cases, traditional REST platforms are not adept at supporting them. Emerging open-source technologies like Protobug, gRPC and HTTP/2 are growing increasingly popular for various companies to support their microstructure needs. However, organizations are very conscious of the challenges they will face while bringing monolithic API implementations of the past into microservices. There are a lot of things that need to fall in place, but developer culture and team maturity is foremost.

“It is advisable to take a slower approach, starting first with the team and culture building around micro-services before the actually moving existing technology.” – John Faminella ( @jxxf)

Have Additional API Strategy Takeaways?

We want to hear from you! Were you in attendance at APIStrat? What were your big takeaways from this year’s event? If not, we’d love to hear the lessons you’ve heard in setting up an API strategy for your organization.