As APIs have matured, we’ve celebrated the most popular ones by welcoming them to the API Billionaires Club. The billionaires are those who measure API requests in the billions–many per month, a few per day. While it’s been a good benchmark thus far, there are downsides to using it: API requests is dependent on many things about an API. In many cases, more requests is not a good thing for either the provider or the developer. It reminds me of the early dot com days and the focus on hits, a mostly meaningless stat with a few similarities to API requests.
The pageview has some troubles of its own. What’s it mean to have many pageviews per user? Either our visitors are all very engaged, or we’ve made the site difficult to use. Indeed, many web publishers break up their stories into several pages to pad those pageview stats.
Just as hits and pageviews can be manipulated by the makeup of a site, APIs can be designed to increase or decrease the number of requests. I doubt any providers have changed their API designs in order to land in the Billionaires Club. But everyone is hopefully considering the trade-offs of the number of API requests and the size of each API response.
One billionaire is making changes. Netflix API requests have a hockey stick growth curve anybody would want. But architect Daniel Jacobson instead set out to decrease the number of requests. Devices using the Netflix API make up a huge percentage of the company’s requests. Yet, for a standard home screen, the device has to make several requests. It retrieves the current user information, the items in their queue, the newly available titles, top comedies, top drama, etc. Each of those is an API call. Scroll one of those lists far enough and the device needs to make another call. Jacobson’s solution is to create an endpoint for each device. It only needs to make one call to that endpoint, for the user’s home screen. A dozen requests become only one.
Location platform foursquare has a special “multi” endpoint to its foursquare API. Using it, developers can make more than one call at once. Common groups of calls can get bunched together in one request.
Bunching can be overdone, of course. If the response takes too long to download, the user may consider the site or app too slow. Again, it’s a trade-off.
If an API request is an imperfect metric, what can we use instead? Many providers look at their number of active developers. But that doesn’t really get at how much those developers’ applications are being used. And none of what I’ve mentioned gets at what most companies would care to see: that the API is either making or saving money in some measurable way.
For now, API requests are the closest to apples-to-apples comparisons that we can get. Despite their drawbacks, when combined with historical numbers they can be used to see the growth in an API.
What other API metrics should providers–or ProgrammableWeb–be tracking?
Icon via Search Engine People Blog