This summer, I interned at Cisco, where I teamed up with my colleague Muddu Krishna to do a 101 for API, Cloud, and Machine Learning. I covered the API portion during this session for which I researched on what we (Product Managers) should know about API. In the process, I spoke to PMs understanding what decisions they make around APIs and read multiple research reports on APIs. Piggybacking on my research for this session at Cisco, I will talk about API 101 for Product Managers in this blog.
This blog is in no way exhaustive or claims to provide an expert point of view. My aim is to give you tidbits about considerations for product managers when it comes to API. I have also referred sources wherever relevant for further reading.
Application Programming Interface or API is an interface of the application to the outside world. In simple words, it’s a protocol of communication between two software applications.
In this blog I will cover the following topics:
- Why APIs have become so popular?
- Expose API – Cocreate value for your product
- Use APIs – Build new functionality
- Anatomy of REST APIs
- Fictional Cisco Network Endpoints API
- Useful Tools and Links
Why have APIs become so popular recently?
In one of the talks of Martin Casado, General Partner at a16z, quite aptly, contrasted the modularization of the software industry to disaggregation of the value chain in the car Industry.
In 1900, the market for the car was small, and hence for a player to be profitable, it had to manufacture most of the parts of the car. Fast forward 90 years, the care industry was big enough to accommodate individual tire manufacturer and battery maker. This strategy also helped in expansion. For example, Ford could partner with a local supplier to expand in Asia.
An equivalent model could be seen in the software industry. In the 1990s, Microsoft was on working everything related to software from OS to application. Fast forward 30 years, a typical mobile app now used 8-10 APIs. For example, Uber uses Twilio to enable calls between driver and rider, Google Map for fetching GPS locations, Stripe for enabling payments, and Facebook SDK to allow you to login.
We could clearly see three main reasons for the growth of usage of APIs:
- Rise of microservices: Decoupling of applications into small services for parallelizing development. Netflix’s iterative transition from a monolith to a microservices architecture, which helped it to scale its content across a variety of screen sizes and device types is one of the most famous microservices success stories. Increasingly, microservices are packaged as APIs to make them shareable and manageable throughout the organization and with outside developers.
“According to Red Hat report, Amazon’s CEO Jeff Bezos famously issued a stern warning in 2003 to all of the company’s internal software teams, that every single service and system within the company had to be made accessible only by a well-documented API. This edict is often credited with Amazon’s later ability to create new opportunities by exposing previously internal processes.”
(Further reading – Why microservices need API management?)
- Speed to market: Using APIs, a developer could build new functionality with just a few lines of code, increasing speed of execution. Imaging Uber first building Google Map and Twilio before even building the core application logic – matching driver and rider. It would have taken ages.
- Low cost: In most cases, API providers, especially aggregators such as Twilio and Stripe, would offer better rates than the investment required from an individual developer to get similar services. These API providers would get a huge volume discount and efficiency gain part of which is transferred to API consumer.
Now that we have understood why APIs have become popular, it’s time to understand how Product Managers could leverage APIs.
Expose API – Cocreate value for your product
Countless products expose APIs for third-party developers to extend the functionality or customize the product experience. Here are a few examples:
- Salesforce AppExchange, an enterprise cloud marketplace with more than 300 ready-to-install apps and solutions built by a third-party developer using Salesforce API, generates 50% Salesforce’s revenue.
- Opening of Facebook API to game developers including Zynga led to the big boom in the social gaming industry. At one point in time, Gaming accounted for 30% of the Facebook revenue.
- Understanding that it can’t solve every problem of customers, Intuit opened it’s APIs for outside developers to build tools for small businesses – a platform-oriented approach.
- Similarly, Cisco, where I interned this summer, allows third-party developers to build on top of their products using APIs and SDKs.
However, as a Product Manager, here are a few considerations for us:
- Platform Approach (+): Exposing APIs for third-party developers, product developers solve disparate problems for customers and increase the value created (and captured) by the product. Solving complex and multitudes of problems would be extremely difficult without collaborating with other developers.
- Misure of data (-): As we have seen in the famous case of Cambridge Analytica, data misuse by third parties could be a big concern.
- Increase in cost (-): API access management, security, and regular testing could significantly add to development cost.
Hence, the decision to expose API isn’t a straightforward one. It’s critical to start with the end goal – either you have a significant size that you could attract third-party developers to build great products on top (Salesforce) or your business model makes it crucial to expose API in order to extend product functionality (Slack).
Use APIs – Build a new functionality
Next, APIs could be used to consume data and resources of a different product to build new product functionality.
Let’s talk about a few examples of this case:
- Twilio (Programmable Communication): Using Twilio APIs, developers could offer voice and text-based communication functionality in the App.
- Stripe (Programmable Payments): Using Stripe APIs, developers could add a range of payment options with just a few lines of codes.
- AWS S3 (Programmable Storage): Amazon S3 offer reliable, scalable object storage. Using S3 APIs, a developer can let users upload directly storage bucket and avail features such as replication and versioning of files.
Again, here are a few considerations for Product Managers when deciding whether to use third party API:
- Speed to market: Using a third party API significantly reduces time investment for a developer, increasing the speed to market. Application developer could focus on core business function and user interaction and leave idiosyncrasies such object storage, payments, and communications to third party APIs.
- Cost: In most cases, third-party APIs would cost less, but it’s important to evaluate the trade-off of building in-house.
- Reliability: Depreciation of public APIs has been a huge issue in the tech industry for developers. That’s why it’s important to explore the reliability and longevity of API. Uber recently invested in in-house tool to reduce the dependency of Twilio, tumbling Twilio stocks.
Anatomy of REST APIs
For this blog, we will restrict our discussion to REST APIs.
At the core, it’s a client-server model. A client makes a “Request”, and serves gives the “Response”. There is a set of defined method for Request – Http Methods and data types for Response – JSON or XML.
A client could be a web browser, mobile app, Alexa, or a microservice. For example, Spotify running on your mobile app or Alexa will make a call to a Spotify server, which based on the logic built-in database gives a response.
One of the key aspects of REST is “Stateless”. It signifies server doesn’t store any application data that is required to serve subsequent requests from clients. This architecture style helps in scaling the service to 1000s of clients.
Fictional Cisco Network Endpoints API
Assume you have information of all the access points in Cisco office in either a database (or excel). Now, let’s build a protocol for an outside developer to access this information.
Objectives of this protocol:
- Users could see the output without being bothered about the complexity of formulas and functions in your excel file
- It’s scalable: Multiple clients can access the data.
- Users could use the data for further analysis
Constrains:
- You don’t want people to break the formulae
- You should be able to make changes in excel without impacting way customer gets data
An API is perfect for the case, as it abstracts the complexities of database and meets the objectives and constraints highlighted here.
REST functions are close to English. For example, take a look at the commands for this fictional API:
- GET me all the Network devices in building 22: GET…/building/22/NetworkDevices/Locations
- DELETE entry of 1st Access Point on floor 3 in building 22: DELETE…/building/22/floor/3/ap/1
- Add 1 more floor in building 22: POST…/building/22{“floors”: 5}
HTTP Methods
The operations available are the same as for web.
- GET: Retrieve a resource
- POST: Create a new resource
- PUT: Replace a resource
- DELETE: Delete all the representations of the resource
Error Codes
Similarly, error codes for REST are the same as for web. Error codes the result of the client’s request.
- 2XX: Okay. For example, 200 indicates request was successful.
- 3XX: Redirection. For example, 301 indicates moved permanently.
- 4XX: Not found
- 5XX: Internal Server Error
Useful Tools and Links
- Postman: It can be used as an HTTP client and for orchestrating APIs – testing and documentation. Postman is extremely easy to get started.
- Swagger: It’s also used for API testing and documentation.
- RapidAPI: It’s an API marketplace with a listing of 10,000+ APIs. A developer can connect to these APIs using RapidAPI’s SDK.
Some material for further reading:
