Usage spectrum of API G/W is quite broad so that the questions are: I would say it totally depend on what the feature you're looking for.
First of all, you need to understand what the microservices means and what it's stemmed from in the history of the evolution in software architecture. Then, you'd understand the API gateway as a design pattern. Other than that, I totally agree with Steven's opinion below.
API gateway is an API management tool that sits between a client and a collection of backend services.
An API gateway acts as a reverse proxy to accept all application programming interface (API) calls, aggregate the various services required to fulfill them, and return the appropriate result.
Most enterprise APIs are deployed via API gateways. It’s common for API gateways to handle common tasks that are used across a system of API services, such as user authentication, rate limiting, and statistics.
At its most basic, an API service accepts a remote request and returns a response. But real life is never that simple. Consider your various concerns when you host large-scale APIs.
You want to protect your APIs from overuse and abuse, so you use an authentication service and rate limiting. You want to understand how people use your APIs, so you’ve added analytics and monitoring tools.If you have monetized APIs, you’ll want to connect to a billing system.You may have adopted a microservicesarchitecture, in which case a single request could require calls to dozens of distinct applications.Over time you’ll add some new API services and retire others, but your clients will still want to find all your services in the same place.
Your challenge is offering your clients a simple and dependable experience in the face of all this complexity. An API gateway is a way to decouple the client interface from your backend implementation. When a client makes a request, the API gateway breaks it into multiple requests, routes them to the right places, produces a response, and keeps track of everything.
An API gateway’s role in API management
An API gateway is one part of an API management system. The API gateway intercepts all incoming requests and sends them through the API management system, which handles a variety of necessary functions.
Exactly what the API gateway does will vary from one implementation to another. Some common functions include authentication, routing, rate limiting, billing, monitoring, analytics, policies, alerts, and security.
An API Gateway is a façade and an entry point. In my view, it’s used as a façade is it’s defining characteristic.
As a façade it abstracts the service implementation from the service consumer ie if the API is my\savingsaccount\1\balance, the consumer of that service need not be aware that the implementation is Cobol on an IBM Mainframe or cached data on Redis, nor should the consumer care so long as the information about the requested account balance is returned within expectations (the “contract”). As a façade, the API Gateway abstracts the “what” do you want from the “how” it is provided. In this sense it acts as a router and may leverage a protocol converter, abstracting the business service from the technical implementation.
As an entry point, the Gateway protects the service provider from unauthorized access by ensuring only authenticated requests are made, facilitating authorization by associating authenticated requests with specific trusted profile tokens that can then be used by the service implementation ie if the API is my\savingsaccount\1\balance, the gateway may route the request based on the associated token, no token for “savings account”= no routing to service implementation, but the decision on whether the authenticated requestor is allowed to see the balance for account “1” is the responsibility of the service implementation (either by evaluating each request or by providing finer-grained authorization tokens to be returned by the authentication service to the API gateway). The API Gateway entry point may also provide protection against threats such as DDoS and code injection both directly, and in conjunction with underlying firewall and load balancing capabilities.
The API Gateway should also provide information for monitoring and analytics so as to allow an over-arching API management capability to provide API contract and SLA management.
API Gateway is a unique entry point for clients to consume the API services which are deployed in the backend systems. You can imagine yourself going to Pub. Bouncer, in this case, is API GW, and accessing drinks once you get inside is representations of API services. (if it's of so bad example to compare, just ignore this).
However, coming back to the core part of API GW. Authentication, Security, Traffic control, Logging.
* Protects the backend services. Only authorized clients will get access.
* GW will help you manage this depends on how you want to protect the service.
* Spike arrest, Quota limit, Concurrentratelimt
* GW will help you to manage role-based access
* Administrator, Deployer, Monitor
* GW will help to manage routing, composition and protocol translation
* It depends on which GW you are going to make use of and to what scale.
* We have both Apigee and CA7
* Apigee is in AWS Cloud facing the internet, intranet and extranet traffic
* Whereas CA is appliance version and just at on-premise.
* So, it depends on your need and the features of each GW vary. Products like Apigee will give you the flexibility to define env (Trial, Test, Prod) and Productization is a great feature too.
Principal Architect at a tech services company with 11-50 employees
Real User
Jun 4, 2020
API Gateway provides a centralized control centre for API provisioning. It faciliates standard ways for securities, service policy, logging etc application. When number of APIs are large, this much reduce development effort and promot standardization of common practice
Executive Advisor, SOA Enterprise Services at Anthem Blue Cross Blue Shield
User
Jun 3, 2020
This is answered on numerous external referenced articles, specifically this one in Developer Zone( see reference): "An API gateway provides a single, unified API entry point across one or more internal APIs.They typically layer rate limiting and security, as well. An API Gateway can help provide a unified entry point for external consumers, independent of the number and composition of internal microservices." The key is understanding the need to decouple the external consumer from the internal microservice using an architectural concept called "proxy", which is simply providing an independent way of getting to the data that is not directly coupled to a microservice. There are downsides as well, one of which is separately maintaining the set of API proxies on an API Gateway in addition to maintaining the portfolio of microservices. See the following article for a good summary of positives/negatives:
Reference: dzone.com/articles/why-do-microservices-need-an-api-gateway Note: These are my personal views from an architecture perspective.
API Management involves overseeing APIs in a scalable, secure, and efficient manner. Enterprises use these solutions for API exposure, control, and enhancement, ensuring seamless communication between their applications and services. This category covers a comprehensive range of tools designed for efficient API lifecycle management, addressing key operational aspects such as API creation, deployment, security, analytics, and monetization. Businesses find these tools essential for...
Usage spectrum of API G/W is quite broad so that the questions are: I would say it totally depend on what the feature you're looking for.
First of all, you need to understand what the microservices means and what it's stemmed from in the history of the evolution in software architecture. Then, you'd understand the API gateway as a design pattern. Other than that, I totally agree with Steven's opinion below.
API gateway is an API management tool that sits between a client and a collection of backend services.
An API gateway acts as a reverse proxy to accept all application programming interface (API) calls, aggregate the various services required to fulfill them, and return the appropriate result.
Most enterprise APIs are deployed via API gateways. It’s common for API gateways to handle common tasks that are used across a system of API services, such as user authentication, rate limiting, and statistics.
Why use an API gateway?
www.softwareag.com
At its most basic, an API service accepts a remote request and returns a response. But real life is never that simple. Consider your various concerns when you host large-scale APIs.
You want to protect your APIs from overuse and abuse, so you use an authentication service and rate limiting. You want to understand how people use your APIs, so you’ve added analytics and monitoring tools.If you have monetized APIs, you’ll want to connect to a billing system.You may have adopted a microservicesarchitecture, in which case a single request could require calls to dozens of distinct applications.Over time you’ll add some new API services and retire others, but your clients will still want to find all your services in the same place.
Your challenge is offering your clients a simple and dependable experience in the face of all this complexity. An API gateway is a way to decouple the client interface from your backend implementation. When a client makes a request, the API gateway breaks it into multiple requests, routes them to the right places, produces a response, and keeps track of everything.
An API gateway’s role in API management
An API gateway is one part of an API management system. The API gateway intercepts all incoming requests and sends them through the API management system, which handles a variety of necessary functions.
Exactly what the API gateway does will vary from one implementation to another. Some common functions include authentication, routing, rate limiting, billing, monitoring, analytics, policies, alerts, and security.
An API Gateway is a façade and an entry point. In my view, it’s used as a façade is it’s defining characteristic.
As a façade it abstracts the service implementation from the service consumer ie if the API is my\savingsaccount\1\balance, the consumer of that service need not be aware that the implementation is Cobol on an IBM Mainframe or cached data on Redis, nor should the consumer care so long as the information about the requested account balance is returned within expectations (the “contract”). As a façade, the API Gateway abstracts the “what” do you want from the “how” it is provided. In this sense it acts as a router and may leverage a protocol converter, abstracting the business service from the technical implementation.
As an entry point, the Gateway protects the service provider from unauthorized access by ensuring only authenticated requests are made, facilitating authorization by associating authenticated requests with specific trusted profile tokens that can then be used by the service implementation ie if the API is my\savingsaccount\1\balance, the gateway may route the request based on the associated token, no token for “savings account”= no routing to service implementation, but the decision on whether the authenticated requestor is allowed to see the balance for account “1” is the responsibility of the service implementation (either by evaluating each request or by providing finer-grained authorization tokens to be returned by the authentication service to the API gateway). The API Gateway entry point may also provide protection against threats such as DDoS and code injection both directly, and in conjunction with underlying firewall and load balancing capabilities.
The API Gateway should also provide information for monitoring and analytics so as to allow an over-arching API management capability to provide API contract and SLA management.
API Gateway is a unique entry point for clients to consume the API services which are deployed in the backend systems. You can imagine yourself going to Pub. Bouncer, in this case, is API GW, and accessing drinks once you get inside is representations of API services. (if it's of so bad example to compare, just ignore this).
However, coming back to the core part of API GW. Authentication, Security, Traffic control, Logging.
* Protects the backend services. Only authorized clients will get access.
* GW will help you manage this depends on how you want to protect the service.
* Spike arrest, Quota limit, Concurrentratelimt
* GW will help you to manage role-based access
* Administrator, Deployer, Monitor
* GW will help to manage routing, composition and protocol translation
* It depends on which GW you are going to make use of and to what scale.
* We have both Apigee and CA7
* Apigee is in AWS Cloud facing the internet, intranet and extranet traffic
* Whereas CA is appliance version and just at on-premise.
* So, it depends on your need and the features of each GW vary. Products like Apigee will give you the flexibility to define env (Trial, Test, Prod) and Productization is a great feature too.
API Gateway provides a centralized control centre for API provisioning. It faciliates standard ways for securities, service policy, logging etc application. When number of APIs are large, this much reduce development effort and promot standardization of common practice
This is answered on numerous external referenced articles, specifically this one in Developer Zone( see reference): "An API gateway provides a single, unified API entry point across one or more internal APIs.They typically layer rate limiting and security, as well. An API Gateway can help provide a unified entry point for external consumers, independent of the number and composition of internal microservices." The key is understanding the need to decouple the external consumer from the internal microservice using an architectural concept called "proxy", which is simply providing an independent way of getting to the data that is not directly coupled to a microservice. There are downsides as well, one of which is separately maintaining the set of API proxies on an API Gateway in addition to maintaining the portfolio of microservices. See the following article for a good summary of positives/negatives:
Reference: dzone.com/articles/why-do-microservices-need-an-api-gateway
Note: These are my personal views from an architecture perspective.