Digital Innovation Gazette: Mobile Development
The Evolution of APIs
By Tim Kridel for Digital Innovation Gazette
Mobile operators sometimes offer application programming interfaces (APIs) to help developers create features that make their apps stand out in the marketplace. Those benefits can rub off on the operator by helping make its version of a smartphone more attractive, which is one reason why the selection of operator APIs is steadily growing.
“The most advanced operators are extending the number of APIs they offer,” says Heavy Reading analyst-at-large Caroline Chappell. “Telefónica has identified around 50 APIs, not all of which are ready yet.”
Another reason why operators are increasingly offering APIs? They enable their network to cater to the enormous diversity of customer interests, particularly in niche categories.
“Operators are becoming more realistic about the long tail, realizing that this is going to be difficult to reach and not especially lucrative, so they are concentrating more on providing APIs for internal and trusted third-party developers and enterprise developers,” Chappell says.
Mobile App Development and APIs: What to Consider
APIs are a familiar concept for any developer. But if you’re new to the mobile operator variety, there are a few things to consider, including type, cost and where to get them. The Sprint Services Framework, for example, offers network-initiated APIs. That means the APIs use network-based resources — as opposed to only software on the smartphone or tablet — to provide developers with access to information such as location, messaging and device status.
“The primary benefit to the developer of this framework approach is the ability to access all of these services without the need to maintain a unique connection to each back-end network element independently,” says Brian Smith, Sprint’s product and development director. “Being network-initiated, there is no dependency on an application that resides on the device,” continues Smith. “[That permits] the developer to create an application that may, for example, locate a customer or determine their terminal status (device on, off or roaming) without the constraints, development costs and support headaches associated with creating applications that must work across a multitude of device types and operating systems.”
As their name implies, network-initiated APIs use network resources. This enables them to provide more functionality, which comes at a cost that’s often passed on to developers.
“A device-resident application that requests the location of a device using solely the GPS capability may be free,” Smith says. “However, the value-add for network-initiated APIs like location includes the ability to locate a device using network triangulation (including indoor location) and cell-sector location if GPS is turned off on the device. Each of the operators offering a network API solution will have individual requirements for cost, acceptance and on-boarding for use of their platforms.”
Some APIs enable developers to have the operator take care of billing, thus eliminating that overhead cost. Other APIs enable services that might cost the developer more to create and support on its own.
“For example, we offer an in-app payment API that lets developers charge for content or additional capabilities that are sold within their application,” says Jon Summers, senior vice president of growth platforms at AT&T, which currently offers 79 APIs across 14 categories. “These charges are billed directly to the AT&T bill. And Our AT&T Watson speech API provides developers with speech transcription and translation capabilities for their apps. Providing the right APIs will enable the developers to design apps faster and more cost-effectively.”
Is There a Catch?
One potential downside of operator-provided APIs is that developers have to modify their apps for each operator. That can limit each version’s addressable market to that operator instead of, say, all iPhones. But that situation is slowly changing.
“Three Canadian operators — Telus, Rogers and Bell Canada – have collaborated to roll out common APIs based on the GSMA OneAPI standard,” Chappell says. “Four Polish operators have signed a letter of intent to harmonize their APIs.”
Another example is the five operators — AT&T, Deutsche Telekom, Vodafone, Verizon Wireless and Telefónica — that plan to offer access to one another’s APIs. “[Those] five are planning to federate their APIs, so that if one operator gets an API call that it recognizes is for a partner operator’s API, it will pass the call to that operator,” Chappell says. “This means the operators can continue to use their own APIs rather than having to harmonize/standardize them.”
“Operators do acknowledge that not having common APIs is a problem,” continues Chappell. “But equally, it would be a large challenge to try and standardize them across multiple operators.”
Besides participating in the upcoming five-operator app store, AT&T is also using the GSMA to make more and more of its APIs available across other operators. “For example, our speech API includes a suite of seven different AT&T Watson-enabled speech recognition and transcription capabilities,” Summers says. “This API can be used by any application regardless of the carrier network.”
APIs: Where Do You Get Them?
The operators themselves are an obvious source of APIs. But as the industry evolves — the aforementioned five-operator joint effort is one example — so do the options for getting operator APIs. Sprint, for example, provides them directly and through its Solutions Enablers.
“Sprint’s Solution Enabler partners provide a valuable resource for developers with a need to access APIs, but who may not want to fully integrate directly with the Sprint platform,” Smith says. “These partners also serve as API aggregators and can provide access to APIs across multiple operators.”
Many mobile operators have sister companies in the wireline telephony or TV businesses. Those operators’ APIs can sometimes be useful for developing mobile apps that work with non-mobile services, such as a social networking app that can interact with a TV set-top box.
“We have a U-verse-enabled API,” Summers says. “This allows a developer’s app to interact with the AT&T U-verse IPTV service via the AT&T U-verse receiver. Once downloaded and launched by the customer and paired with a receiver, the app can send remote control commands, receive data on what is being watched, detect events such as channel changes, and direct the U-verse receiver to display content from specially configured websites. Integrating our various platforms and exposing them via APIs is a big focus for us.”
Regardless of where mobile app developers get operator APIs, it’s clear that they’re using them. “When we launched this initiative in 2009, we averaged about 300 million API calls on our network per month,” Summers says. “By mid-2012, we were averaging about 5 billion calls per month.”
Tim Kridel
has been covering all things tech
and telecom since 1998 for a variety of publications and analyst firms. Based
in Columbia, Mo., he still enjoys the childhood hobby that led to a career
writing about technology: ham radio.
He is a frequent contributor to Digital Innovation Gazette.
