The API Train Wreck Part-1

ApelbaumYaacov API Train Wrack

Developing a commercial grade API wrapper around your application is not a trivial undertaking. In fact, in terms of effort, the development of an outbound facing API can dwarf all combined application development tasks by an order of magnitude.

I’ve seen some large development organizations attempt to open their internal platform to the world just to watch in horror as their core systems came to a screeching halt before ever reaching production.

In this and a follow-up posting, I’ll try to provide you with some hands-on tips about how you can improve the quality of your API and more efficiently ‘productize’, ‘commercialize’, and ‘operationalize’ your data service.

It’s 9 PM, do you know who’s using your API?
Do you have accurate and up-to-date KPIs for your API traffic and usage? Are these counters easily accessible or do you need to troll through numerous web server and application logs to obtain this data? Believe it or not, most APIs start as orphaned PoCs that were developed with the approach of ‘do first, ask permission later’.  Things like usage metrics are often put on the back burner until project funding and sponsorship roll in.

Paradoxically, due to their integrative effect, application APIs can provide the biggest boost to traffic and revenue, but at the same time they can become your biggest bottleneck.

So my first tip is to build usage information into your core functions. Before you embark on an API writing adventure, your product management and development teams should have clear answers to these questions:

How many clients, applications, and individual developers will use your API?

  • Will you offer public and private versions of it?
  • What will the distribution of your clients, apps, and developers by type and location be?
  • Who will the the top tier customers be? Developers? Partners?
  • What parts of the API will be used most heavily?
  • What will the traffic breakdown between your own services and 3rd party services be?
  • What will the aggregate per application and per customer transaction volumes be?
  • How fast and reliable will our service be, (i.e., response, latency, downtime, etc.)?
  • What are the architectural and technical limiting factors of your design (i.e. volume)?
  • How will the API be monitored and SLAd?
  • What type of real-time performance dashboards will you have?
  • How will the public facing API usage effect the rest of your platform, (i.e., throttling)?
  • Will you handle error routines generically or identify and debug specific messages?
  • Do you need to support auditing capabilities for compliance, (i.e SOX, OFEC, etc.)?
  • What will the volume of the processed/delivered data be, (i.e. from a third parties)?

Asking these questions—and getting good answers to them—is critical if you plan to develop a brand new SaaS platform to expose your internal platforms to the world.

This information is also critical to your ability to establish contractual relationships with your internal users and external customers. Depending on the type of information you serve, it may be also mandatory for compliance with state and Federal regulations.

Collecting the correct performance metrics and mapping them to your users and business functions will help you stay one step ahead of your user’s growing demands.

© Copyright 2013 Yaacov Apelbaum. All Rights Reserved.

2 thoughts on “The API Train Wreck Part-1

  1. How would you go about determining if you need to develop both a “public” and “private” versions of your API? Isn’t it sufficient to just enhance your private API and expose it to the public?

    • Hi David,

      My two main considerations would be:

      1. Do I have the time and budget to develop two API flavors?
      2. What is the expected volume and revenue from your public API?

      If the answers are ‘yes’ and ‘significant’, I would consider splitting the APIs.

      Yaacov

Leave a Reply

Your email address will not be published. Required fields are marked *