Edition 0 Updated to asp. Net core 0

Main features in the API Gateway pattern 
An API Gateway can offer multiple features. Depending on the product it might offer richer or simpler 
features, however, the most important and foundational features for any API Gateway are the 
following design patterns: 
Reverse proxy or gateway routing.
The API Gateway offers a reverse proxy to redirect or route 
requests (layer 7 routing, usually HTTP requests) to the endpoints of the internal microservices. The 
gateway provides a single endpoint or URL for the client apps and then internally maps the requests 
to a group of internal microservices. This routing feature helps to decouple the client apps from the 
microservices but it’s also convenient when modernizing a monolithic API by sitting the API Gateway 
in between the monolithic API and the client apps, then you can add new APIs as new microservices 
while still using the legacy monolithic API until it’s split into many microservices in the future. Because 
of the API Gateway, the client apps won’t notice if the APIs being used ar
e implemented as internal 
microservices or a monolithic API and more importantly, when evolving and refactoring the 
monolithic API into microservices, thanks to the API Gateway routing, client apps won’t be impacted 
with any URI change. 

---

45 
CHAPTER 3 | Architecting container and microservice-based applications 
For more information, see 
Gateway routing pattern
. 
Requests aggregation.
As part of the gateway pattern you can aggregate multiple client requests 
(usually HTTP requests) targeting multiple internal microservices into a single client request. This 
pattern is especially convenient when a client page/screen needs information from several 
microservices. With this approach, the client app sends a single request to the API Gateway that 
dispatches several requests to the internal microservices and then aggregates the results and sends 
everything back to the client app. The main benefit and goal of this design pattern is to reduce 
chattiness between the client apps and the backend API, which is especially important for remote 
apps out of the datacenter where the microservices live, like mobile apps or requests coming from 
SPA apps that come from JavaScript in client remote browsers. For regular web apps performing the 
requests in the server environment (like an ASP.NET Core MVC web app), this pattern is not so 
important as the latency is very much smaller than for remote client apps. 
Depending on the API Gateway product you use, it might be able to perform this aggregation. 
However, in many cases it’s more flexible to create aggregation microservices under the scope of the 
API Gateway, so you define the aggregation in code (that is, C# code): 
For more information, see 
Gateway aggregation pattern
.