I joined a project, that already has built all the microservices backends, and they have many API endpoints, something like below:
example1.com/api/a
example2.com/api/b
example3.com/api/c
example4.com/api/d
Recently, the manager of the company asked me to aggregate all the endpoints into one, how can we have just one API endpoint?
Something like below:
example.com/api/a or b or c/*
Is this even possible without help of developers? I mean, no code side changes?
Some of the ideas I have are.
Nginx proxy in front
API GW (but not sure which one suite best for this)
If you just want to get one endpoint and not to aggregate and merge data in one service, AWS API Gateway will help you. It will be a single entry point for client applications and you can re-route multiple requests on multiple backend services on gateway without changing any code.
You can do some integration on API Gateway:
https://api-gw.example.com/users -> integration request on service: example1.com/api/a
https://api-gw.example.com/orders -> integration request on service: example2.com/api/b
Additionally, you can have single authorization mechanism for these resources on Gateway, like Cognito, AWS_IAM, or Custom Authorization.
If you need to aggregate some API responses, you can use lambdas or BFF Pattern.
Related
In our application, we adopted a microservices architecture pattern. I am bt familiar with microservices architecture but I have a few doubts:
API Gateway: Userful to have a single point of entry to connect with all microservices and on top of that we can enable other features like routing, aggregates, load balancing, etc. for this we are using Ocelot API gateway.
Aggregator: There are many scenarios where, we need to call multiple services, fetch the data and combine them into an API response.
I would like to know, should we use API Gateway and Aggregator?
Also, I checked Ocelot documentation and Ocelot does provide the Aggregate feature but only for GET calls. but in our API implementation, we have a POST call to fetch the data.
also, Just wanted to confirm, that we have ActiveMQ in place for asynchronous communication between services mostly when we have transactional data.
so, should this transactional communication also be taken care of by the Aggregator service or from the API gateway?
I would really like to understand if my reasoning is correct here.
Thank you in advance!
I have a Web API which has two endpoints:
/tenant1/xxx
/tenant2/xxx
The Web API serves multiple tenants and it is hosted as a single instance. Now I have to public this Web API to the outside for using, from the third party, they don't need to know which tenant they should call, instead, they call /api/dosomething (another web API), and inside that API, I will look at the parameter and decide which tenant I should reroute. I use Ocelot as API Gateway but searching on the document I can not find the condition routing. Can anyone help me with this?
Ocelot supports DelegatingHandler which play as middleware for out-going request
I've been doing a ton of research on Microservices however I cannot find a single piece of code that is written for an API gateway. I understand that between the clients and services you would have an the API Gateway which allows a client to make 1 requests over IoT to the gateway and then the gateway can make many requests internally to services which then build up a response. Now from an article on NGINX
The API Gateway is responsible for request routing, composition, and protocol translation.
use case
Suppose we support 2 clients. Android and an Angular App (browser) and let's make a tangible user story that the client is an online shopping store.
the shopping store would then have different services broken out into servers and each service could be built on a different platform/language with a different database. They are completely self contained so that they can scale in the cloud really quickly without having to scale the entire application. If there is some intense Algorithm that needs to run for payment. Then the payment services can quickly spin up a few more servers to balance the load and decrease user wait time.
but that could be written in Java which could have a HTTP/REST exposed api to be consumed. However what if it's written in say c++/Golang/Node it doesn't really matter what language, but instead of exposing their api via HTTP it's by a different protocol what would that mean on the api gateway - how would it handle the response?
the client goes and makes a request to the home page where we have 3 things loaded
shopping cart
list view of shoppings items
current specials
the client would only make 1 request to the api gateway let's say to apigateway/apiv1/home to the api gateway which then would have 3 requests to the services so
serviceShopping/apiv1/shoppingList
serviceCart/apiv1/cart
serviceSpecial/apiv1/specials
at this point the 3 services could be written in a different language and use a different protocol. How would those 3 services be requested and on the response back to the client (a single response) how would it be concatenated? json object with a specific schema? this is where I get confused...
sorry for the long post it's a simple question I think, but I needed to setup something I can conceptualize with and explain.
I am experimenting with Mule API management these days. What I come to know is we can deploy our API to one of these:
A Mule Runtime
An API Gateway
In the documentation, it is said that we should go with option 1 when we want to separate out the implementation of your API from the orchestration. What does it mean?
Can any one please explain in detail?
Policy management from API Platform and analytics generation can be achieved only by using a correctly configured API Gateway, which is a superset of Mule EE (current version is API Gateway 2.1.0 which contains Mule EE 3.7.2).
Depending on your architecture you may have different solutions.
For example:
Proxy running on API Gateway, implementation API running somewhere
else (eg. Mule EE/CE, Tomcat, cobol server, etc)
Proxy and implementation API running on the same API Gateway
Implementation API
managed directly from API Platform without using the autogenerated
proxies.
HTH :-)
Not exactly sure what they mean there, because on this page: https://developer.mulesoft.com/docs/display/current/API+Gateway they also mention this:
Note that the API Gateway, because it acts as an orchestration layer
for services and APIs implemented elsewhere, is technology-agnostic.
You can proxy non-Mule services or APIs of any kind, as long as they
expose HTTP/HTTPS, VM, Jetty, or APIkit Router endpoints. You can also
proxy APIs that you design and build with API Designer and APIkit to
the API Gateway to separate the orchestration from the implementation
of those APIs.
So both methods technically allow you to separate API from orchestration, as your API gateway application could simply proxy another Mule application elsewhere that performs the orchestration. But my understanding of the two options are:
The API gateway is a limited offering that allows you to use a subset of Mule's connectors, transports and modules such as ApiKit and HTTP, it allows you to expose and API then use http to connect to whatever backend systems you want as a proxy and perform the orchestration in the API layer.
By using the Mule runtime operation, it gives you much more flexibility and allows you to compose as many applications as you want using the full range of connectors etc. and separate out the different aspects of your applications into as many layers as you want as separately deployable entities that you can deploy to on-premise standalone instances or Cloudhub etc.
#Ryan answer is more or less on the mark, however if you do choose the Mule ESB offering you will loose out on the API Management and governance functionality that API gateway provides OOTB.
These include
Lets you enforce runtime policies and collect data for analytics
Applies policies to APIs or endpoints around security, throttling,
rate limiting, and more
Extends PingFederate to serve as identity management and OAuth
provider for your APIs
Lets you require or restrict certain behaviors in a few simple steps
Lets you add or remove policies at runtime with no API downtime
Manages access to your API by issuing contract keys
Monitors the API to confirm it is meeting all contract terms
Ensures compliance with service level agreements (SLAs)
In my opinion go with API Gateway/Manager if your API will be consumed my third party developers with whom you might not have too many interactions (think public API's) else Mule ESB should be good.
You should be able to migrate from Mule ESB to API Manager (and vice versa) also easily if you need to, so I do not think you will get locked into your decision
PS: Content copied from here
I am working on one school project, And my task is to make a simple api gateway, which can placed between any of the 3rd party api and the end users, tha gateway can be used for defining usage limits of the api or to do some security analysis, I am totally new to this, I know the basic concept of API gateway, but don't know how do I implement it using JAVA.
Can anyone please give me some starting point where to start implementation of API gateway?
And what are the frameworks I should use and for what purpose?
Thanks,
Nixit Patel
In a nutshell, API gateway exposes public APIs, applies policies (authentication - typically via OAuth, throttling, adherence to the the defined API, caching, etc.) and then (if allowed) optionally applies transformation rules and forwards the call to the backend. Then, when the backend responds, gateway (after optionally applying transformation rules again) forwards the response to the original caller. Plus, there would typically be an API management solution around it providing subscriber portal, user management, analytics, etc.
So basically any web service framework would work as a quick DYI solution.
You can also use plugin model of an open-source load-balancer such as NGINX.
Or take an open-source API Gateway to learn from it - e.g. WSO2 API Manager (the easiest way to see it in action is the hosted version: WSO2 API Cloud)