Chapter 7, API Management and Consumption Patterns gpt Flashcards
What is an API or API proxy in a cloud native application?
An API or API proxy represents a business capability of a cloud native application exposed to consumers in a managed way, typically backed by one or more backend microservices and hosted in a separate API gateway runtime.
Page: 413
An API or an API proxy represents a business capability of your cloud native application that is exposed to consumers in a managed way. An API may be backed by one or more backend microservices and is usually hosted in a separate API gateway runtime.
Where should the business logic reside in a cloud native application?
The business logic should reside with the backend microservices, while the API should only provide capabilities such as security, throttling, and versioning.
Page: 413
The logic of the business capability that we expose should reside with the backend microservices, while the API provides only capabilities such as security, throttling, versioning, and so on. We should try to avoid putting business logic in the API layer, as the underlying service is responsible for supporting the required business logic.
Can a single API offer multiple backend microservices?
Yes, a given API can offer multiple backend microservices. For example, an order API can be backed by an order management capability and an order status capability hosted in different contexts.
Page: 413
A given API can offer more than one backend microservice (for example, an order API can be backed by an order management capability hosted at :/order/management services and an order status capability hosted in a different context (order/status).
Should service orchestrations be created at the API layer?
No, it is not recommended to create compositions such as service orchestrations at the API layer.
Page: 413
But we do not recommend creating compositions such as service orchestrations at the API layer.
How are APIs usually exposed?
APIs are usually exposed via REST/OpenAPI or GraphQL.
Page: 413
APIs are usually exposed via REST/OpenAPI or GraphQL.
What is an API product and how is it used?
An API product is used to present an API to developers via the API developer portal, usually mapped to a high-level business capability and consisting of one or more APIs.
Page: 413
An API product is a concept occasionally used when it comes to presenting an API to developers via the API developer portal. The API product has one or more APIs and is usually mapped to a high-level business capability. For example, in cloud storage services, Storage Services can be the API product, while we can have multiple APIs such as the File API, Blobs API, and Disk API under that one API product.
What is the API gateway and its purpose?
The API gateway is the front door to your APIs, responsible for accepting API calls, applying security validations, quality-of-service attributes, and collecting observability and analytics data.
Page: 417
API gateway: The API gateway is the front door to your APIs. The APIs that you create in front of the downstream microservices are hosted inside the API gateway runtime. None of the roles that we’ve discussed directly interacts with the API gateway, but the API consumers do (for example, the consumers of the mobile and web applications that are built on top of the managed APIs). The API gateway is responsible for accepting the API calls and applying security validations such as tokens, certificates, and other credential validations. It also applies various quality-of-service attributes to the API calls, such as throttling (quotas, rate limiting), caching, and versioning. In certain scenarios, you may also implement lightweight transformation logic (such as JSON to XML, or minor changes to the payload), but again we should not try to expose any logic related to the business capability of the API that we offer. An API gateway is also responsible for collecting all the data related to observability and API analytics.
What should not be exposed in the API gateway?
Business capability logic should not be exposed in the API gateway.
Page: 417
In certain scenarios, you may also implement lightweight transformation logic (such as JSON to XML, or minor changes to the payload), but again we should not try to expose any logic related to the business capability of the API that we offer.
What is the API management plane and its functions?
The API management plane is the main interface used by API creators and publishers to control and administer APIs, manage API access policies, users, schemas, and API visibility.
Page: 417
API management plane: The API management plane is the main interface that the API creators and publishers use to control and administer the behavior of the APIs hosted through the API gateway and developer portal. Using the control plane, we can define and create APIs (and API products), change the life-cycle state of the APIs, and manage API access policies such as throttling, caching, security, and versioning. Management of users, schemas, and API visibility are also done at the control plane.
What functionalities does the API developer portal provide to developers?
The API developer portal allows developers to discover, learn about, try out, subscribe to, rate, and provide feedback on APIs, as well as generate security keys and tokens and obtain usage analytics.
Page: 418
API developer portal: The developer portal is where you present your APIs to the application developers so they can discover and learn about your APIs, try them out, subscribe to them (or to API products), rate them, and provide feedback. (This is similar to the concept of an app store that you usually find with mobile devices such as iPhone or Android). The developer portal also allows developers to generate required security keys and tokens and use them when building applications that consume those APIs. Developers may also use the developer portal to obtain analytics on their own usage.
Which components are mandatory and optional in the API Gateway pattern?
The API gateway is mandatory, while the management plane and developer portal are optional based on the use case.
Page: 418
The API gateway is a mandatory component for implementing the API Gateway pattern, and the rest are optional. Based on your use case, you can choose whether you need a management plane or a developer portal.
How is the API Gateway pattern used in practice?
It is used as a facade on top of existing microservices, with capabilities exposed as APIs through either a bottom-up or top-down approach.
Page: 418
How it’s used in practice: The API Gateway pattern is usually used as a facade on top of existing microservices. Not all your microservices need to be exposed as APIs. When you want to expose a certain capability as an API, you first create a microservice that caters to that capability and then you can create an API by using that microservice as the backend.
Figure 7-2 shows the Order API exposing the business functionalities related to order management in an online application. This requires multiple services to interact, and we may use the Service Orchestration or Service Choreography patterns to implement the service composition. Once we have the composite service (Order service, in this case), API creators/publishers can create an Order API by using the API management plane, and then publish it. Once you publish the API, it becomes available in the developer portal for the app developers. They can then build apps that consume the Order API.
The applications that are built to consume the Order API send requests to the API gateway, where security, throttling, caching, versioning, and other policies are enforced. Since we start from microservices and then expose APIs later, this approach is known as a bottom-up API management technique.
The API Gateway pattern can also be used in a top-down approach, in which we start with the API design. Depending on the use case, this approach requires us to first design the API and then delve into the implementation, where we develop one or more microservices and their interactions.
Top-down API management is usually suitable when you have API management requirements at the time you start building a cloud native application. If you are adopting API management later into the development of your cloud native application, the bottom-up approach works better.
What is the bottom-up API management technique?
The bottom-up API management technique starts with microservices and then exposes APIs, suitable for adopting API management later in development.
Page: 418
Since we start from microservices and then expose APIs later, this approach is known as a bottom-up API management technique.
What is the top-down API management approach?
The top-down API management approach starts with API design and then develops microservices, suitable when API management requirements are defined at the beginning.
Page: 418
Top-down API management is usually suitable when you have API management requirements at the time you start building a cloud native application.
How does the Service Mesh Sidecar as an API Gateway Pattern function?
It involves using a sidecar proxy to function as the API gateway, controlled via the API management and service mesh control planes, allowing microservices to be exposed as APIs.
Page: 424
How does the Service Mesh Sidecar as an API Gateway Pattern work?
Suppose you are already using a service mesh to run your microservices and want to include API management in the same deployment. For the microservices that you want to expose as APIs, you can leverage a sidecar proxy to function as the API gateway in addition to supporting the normal service mesh capabilities. Each service mesh sidecar proxy that is colocated with the microservices can also be controlled via the API management plane and service mesh control plane.
Who interacts with the service mesh control plane versus the API management plane?
Service developers or DevOps interact with the service mesh control plane, while API creators and publishers manage the API lifecycle through the API management plane.
Page: 424
The type of users who interact with the service mesh control plane are different from those who interact with the API management plane. Service developers or DevOps primarily control the service mesh behavior, while API creators and publishers manage the API life cycle.
What are the similarities between a service mesh sidecar proxy and an API gateway?
Both the service mesh sidecar proxy and an API gateway intend to work as proxies and are controlled by separate control planes.
Page: 424
One of the main reasons for using a sidecar proxy as an API gateway for each microservice is that the requirements of a service mesh sidecar proxy and an API gateway are similar. Both intend to work as proxies and are controlled by a separate control plane.
