Unit 4.5 study guide — The value of APIs
Cloud Digital Leader › Unit 4 › Topic 5
The value of APIs
Study guide for Cloud Digital Leader, Unit 4 · Topic 5. This is the topic's lecture in reading form — every slide's teaching, figures and worked examples, in order — followed by the official Google Cloud pages its claims rest on.
What the exam guide asks. Explain the business value of application programming interfaces (APIs).
Objectives, quoted from the exam guide:
- Define application programming interface (API).
- Explain how organizations can create new business opportunities by exposing and monetizing public-facing APIs.
- Discuss the business value of using Apigee API Management.
The value of APIs
What an API is, what exposing one earns, and what managing it adds
What an API is — an interface that lets one application use another's capabilities or data, under a contract. What exposing one earns — a new business channel, and revenue when it is monetized. What managing it adds — Apigee's proxy layer: security, insight, discoverability, and backends that can change without breaking the apps that call them.
The guide's summary for this topic is one line: explain the business value of application programming interfaces, or APIs. Its three objectives build on each other. The first is a definition — and a precise one matters, because every later claim depends on what an API promises. The second asks how an organization creates new business by exposing APIs to the outside world and charging for them. The third asks what an API management platform, and Google's in particular, Apigee, adds on top. So the topic moves from a piece of software, to a product, to a program. Keep that sequence in mind: most exam items in this topic describe a business goal and ask which of those three levels answers it.
What an API is
An interface one application uses to reach another's logic and data
- Software that allows two applications to talk to each other
- Stable, simplified entry points that let developers reuse others' logic
- Web APIs expose that logic and data over the network
- A contract: consumers depend on the API changing predictably
Worked example (synthetic). A food-delivery app shows a restaurant's live menu without storing it. The app calls the restaurant platform's API; the menu logic and data stay with the platform, and the app reuses them through a stable entry point.
Start with the definition, because Google gives two and they fit together. The plain one, from Google's API management page: at its most basic level, an application programming interface, or API, is a piece of software that allows two applications to talk to each other — APIs connect apps to apps, apps to servers, and apps and servers to consumers. The more precise one, from Apigee's documentation: an API is an interface that makes it easy for one application to consume capabilities or data from another application. That documentation then says why it is valuable: by defining stable, simplified entry points to application logic and data, APIs enable developers to easily access and reuse application logic built by other developers. In the case of web APIs, that logic and data is exposed over the network. And one more word turns an API into something a business can build on: contract. Because applications that consume APIs are sensitive to changes, APIs imply a contract — some assurance that, over time, the API will change in a predictable manner. Hold on to the contract; the third objective is largely about keeping it.
Four words that sit around an API
Interface, contract, proxy, management — four different things
| Term | What it is | What it is not |
|---|---|---|
| API | An interface one application uses to consume another's capabilities or data | The application or the data itself |
| Contract | The assurance that the API changes in a predictable manner | A promise that the backend never changes |
| API proxy | A layer that decouples the app-facing API from backend services | A second copy of the backend |
| API management | Developing, designing, monitoring, testing, securing and analyzing APIs | A single API |
Worked example (synthetic). An item describes a bank that rewrites its payments backend while partner apps keep working. The word doing the work is the proxy, which kept the contract, not the API alone.
These four words are used loosely in conversation and precisely on the exam. The application programming interface, or API, is the interface: what one application calls to reach another's capabilities or data. The contract is the promise attached to it — Google's wording is some level of assurance that, over time, the API will change in a predictable manner — which is not a promise that nothing behind it changes. The API proxy is how that promise is kept in practice: API proxies decouple the app-facing API from your backend services, shielding those apps from backend code changes. And API management is the whole discipline around many APIs — Google defines it as the process of developing, designing, monitoring, testing, securing and analyzing APIs for organizations. When an item mixes these, ask which one it is really about: one interface, its promise, the layer that protects the promise, or the program that runs them all.
Exposing and monetizing public-facing APIs
Data and services become a product other people build on
- A new business channel: valuable data and services offered as APIs
- Public and private APIs made consumable and scalable
- Rate plans charge developers — or share revenue with them
- Revenue per API measures the business health of the program
Worked example (synthetic). A logistics firm already tracks every parcel for its own website. Exposing tracking as a public API lets online shops show delivery status inside their checkout — and a rate plan turns each lookup into revenue.
The second objective is where an application programming interface, or API, stops being plumbing and becomes a product. Google names the benefit directly: create new business channels — monetize valuable data and services by making them available to developers as APIs. API management is what makes that feasible at scale; Google says it enables organizations to make both their public and private APIs consumable and scalable, and that a management platform lets businesses unlock the value of their data and services, accelerate innovation, and create new revenue streams. The mechanism for revenue is concrete in Apigee. As an API provider you need a flexible way to monetize your APIs so that you can generate revenue whenever your APIs are used. You bundle APIs into an API product, and add a rate plan to it; the rate plan lets you charge developers for using your APIs, and it can also be configured to share your API revenue with the developers. That last option is worth noticing: monetization is not only charging, it can be paying partners to build on you. And because the revenue is attributable, Google points out that monetization and business metrics, such as the revenue driven through a particular API, let organizations measure the business health of their API ecosystem.
From an API to revenue
Bundle, price, subscribe, call
Figure: A left-to-right flow: API proxies are bundled into an API product, a rate plan is added to the product, a developer subscribes and receives an API key, the developer's app calls the API with the key, and revenue is generated whenever the API is used.
Worked example (synthetic). A weather service offers a free product for hobbyists and a paid product for airlines. Same APIs, two API products — the product, not the API, is what carries the price.
Here is the monetization path as a sequence, because the order is what the exam probes. It starts with proxies for your application programming interfaces, or APIs. As an API provider, you create API products to bundle your APIs and make them available to app developers — Google suggests you think of API products as your product line. A rate plan is added to an API product, and that is where the charge lives. Then a developer has to opt in: to access an API in a monetized API product, app developers must have a subscription to the API product and obtain API keys to send with API requests. Only then do calls earn anything — revenue whenever the APIs are used. Notice two things the figure makes obvious. The price attaches to the product, not to an individual API, so the same APIs can be sold in different bundles. And the key is issued per product, which is why API products are, in Google's words, the central mechanism for access control to your APIs.
Three ways a public API opens new business
Sell it, reach further with it, or unlock what you already own
Figure. Three cards naming how exposing APIs opens new business: a new channel that monetizes existing data and services, a wider audience of developers reached through cloud-hosted API catalogs, and legacy systems unlocked by an API layer on top of existing services.
Worked example (synthetic). An insurer's forty-year-old policy system cannot be rewritten this decade. An API layer over it lets comparison sites quote its policies — a new channel without touching the old code.
Exposing application programming interfaces, or APIs, creates new business in three distinct ways, and scenarios usually lean on one of them. The first is the channel itself: monetize valuable data and services by making them available to developers as APIs — the business sells what it already runs. The second is reach: Google notes that API catalogs can be hosted on the cloud to reach a global audience of developers, whether they are internal, external or a mixture, so the same investment finds partners the sales team never would. The third is the least obvious and often the most valuable: unlocking legacy. Google describes delivering new experiences and services with an API management platform as an abstraction layer on top of existing services, easily connecting legacy technologies to new cloud-native systems and products. An organization does not have to modernize a system before it can earn from it; it can put an API in front of it first.
Apigee: a proxy layer in front of your services
Policies run at the proxy, so the backends behind it can stay as they are
Figure. Client apps send API calls with a key to an Apigee API proxy in the proxy layer. The proxy forwards requests to backend services, including a legacy system, inside a boundary labelled unchanged behind the proxy, and those services read and write business data. The callout notes that apps call the same API while the backends behind the proxy change.
Worked example (synthetic). A retailer moves its inventory service to a new platform over a weekend. Partner apps notice nothing, because they were calling the Apigee proxy, whose API did not change.
The third objective asks for the business value of Apigee, and the value follows from where Apigee sits in front of an organization's application programming interfaces, or APIs. Google describes Apigee as its native API management platform, used to build, manage and secure APIs for any use case, environment or scale. Architecturally, Apigee provides an API proxy layer that sits between your backend services and the internal or external clients that want to use them — that is this figure. Client apps, carrying their API keys, call the proxy. The proxy layer gives you granular control over security, rate limiting, quotas, analytics and more for all of your services. And the business point is on the right-hand side of the picture: because the policies and actions are implemented on Apigee, in the proxy layer, your underlying backend services can remain unchanged. The same position works in the other direction too. Using Apigee proxies isolates API consumers from your backend service, so you can make changes to your backend while client applications keep consuming your services without interruption. The contract from objective one is kept here.
Each Apigee capability, and the business value under it
What the platform does, and why a business pays for it
| Capability | What Apigee provides | Business value |
|---|---|---|
| Discoverability | A developer portal to find APIs, read docs and register | Developers adopt the APIs without a sales call |
| Insight | Security, monitoring with alerting, and usage analytics | Knowing which APIs are used, and by whom |
| Reliability | A consistent interface in front of the backends | Backends change without breaking partner apps |
| Access control | API keys issued when an app registers | The provider decides who may call its APIs |
| Monetization | Rate plans on API products | Revenue whenever the APIs are used |
Worked example (synthetic). A bank's partner team spends weeks onboarding each fintech by email. A developer portal with self-registration turns onboarding into an afternoon — the value is discoverability, not a faster backend.
Read the table column by column: what Apigee does for an organization's application programming interfaces, or APIs, then what a business gets from it. Discoverability: Apigee offers API producers a developer-focused portal where client app developers can discover your APIs, find the documentation they need, and register as an app developer — Google's general definition of a developer portal is a site where developers can find the information and credentials required to use APIs in their client apps. Insight matters because of exposure: Google points out that because API producers make their services available over the web, they must secure and protect them from unauthorized access. Apigee offers advanced API security, API monitoring and analytics features that let producers secure access, monitor uptime and traffic with alerting, and see how their APIs are being used. Reliability: the consistent interface in front of the backends, which we have just seen. Access control: when developers register their app, they receive an API key that gives the app access to the API — and through the app registration process, you control who has access to your APIs. And monetization: rate plans on API products. The exam tends to describe the business pain — slow partner onboarding, blindness about usage, fear of breaking partners during a migration — and expects you to name the capability that answers it.
Apigee, API Gateway, and Apigee hybrid
Three Google options, three different jobs
Figure. Three cards. Apigee: the full API management platform with proxies, policies, a developer portal, analytics and monetization. API Gateway: a consistent API across Google Cloud services, handling traffic management, authorization and monitoring. Apigee hybrid: Apigee with its runtime plane on the customer's premises for compliance or security.
Worked example (synthetic). A health insurer must keep API traffic inside its own data center for regulatory reasons but wants Apigee's portal and analytics. Apigee hybrid is the fit: the runtime runs on its premises.
The guide names Apigee, but a scenario can offer its neighbours as distractors, so separate the three ways Google manages application programming interfaces, or APIs. Apigee is the full platform: Google's native API management platform to build, manage and secure APIs for any use case, environment or scale, with the proxy layer, the developer portal, analytics and monetization. API Gateway is narrower: it enables you to provide secure access to your services through a well-defined API that is consistent across all of your services, regardless of how they are implemented, and it is natively integrated with Google Cloud, handling traffic management, authorization and monitoring for concurrent API calls. And Apigee hybrid answers a constraint rather than a feature: if your compliance and security considerations make on-premises deployment a must, you can host and manage the Apigee hybrid runtime plane on your premises. When an item mentions monetizing, a developer portal or a partner ecosystem, it is asking about Apigee. When it insists the traffic stays on-premises, it is asking about hybrid.
What this topic actually tests
Three discriminations, three objectives
Interface, contract, proxy or program? name which one the item is about. Channel, reach or legacy? the three ways an exposed API earns. Which pain, which capability? portal for onboarding, analytics for blindness, the proxy for change — and hybrid when traffic must stay on-premises.
Close on the three discriminations this topic tests. First, when a definition is in play, decide which of four things the item means: the application programming interface, or API, as an interface, the contract that it changes predictably, the proxy that keeps that contract while backends change, or API management as the program around many APIs. Second, when an item asks how an API creates business, pick the mechanism: a new channel that monetizes data and services through API products and rate plans, a wider reach through cloud-hosted catalogs, or legacy systems unlocked by an API layer on top of them. Third, when an item describes a pain, match the Apigee capability: the developer portal for slow onboarding, analytics and monitoring for not knowing how APIs are used, the proxy layer for changing backends without breaking partners, and Apigee hybrid when the runtime must stay on-premises.