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)
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 basically have a smaller software that is using the Microservice architecture. I am currently using RabbitMQ to do the communication between UI and services and that works great.
However I am thinking about creating a new microservice, a API Gateway, that basically takes the RabbitMQ logic from the UI and encapsulate into a service, which would become the entry point to all the other services.
The benefit is that I would encapsulate the logic that give access to the services and also being able to add authentication in the API Gateway.
However I would need to use HTTP request to interact with the API as I am moving the messaging logic from the UI. Could there be any major drawbacks in this approach?
I have being able to find examples about RabbitMQ and examples about API Gateways but never those two together, I might just be overthinking it a bit.
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 have reading and developing my understanding with SOA, I found this approach of development useful. However there are couple of thing confusing me which are:
Background: we are designing online financial application, recently we are in phase of designing brain storming sessions. (audit & logging need to be done)
1 - how to make sure Secure inter process communication?
My thinking: to restrict external access to these API's by firewall. So these can only be call internally by system.
2 - what will be preferred protocol rest or soap in context of private api (IPC) and public APIs (exposed to clients for e.g mobile,web and desktop)
My Thinking: For read we can use Rest and for ACID compliance transactions we can utilize soap as its provide point to point security. Or for IPC we are thinking to utilize soap as its provide audit mechanism also.
3 - What is Role of API gateway? specially is it involve in inter process communication?
I am confused on this specially with IPC. I think all request even services to services call will perform via API gateway. Kindly elaborate this in detail if I am wrong.
4 - is this possible to keep some services public and some private in micro services architecture? how to logically separate both of them?
What ever I have research we can do this.
5 - What is major difference and pros and cons of SOA and Micro SOA?
My view: Msoa is extention of SOA.
Thanks in advance.
Can anyone draw a diagram or provide link of MSOA architecture diagram with API gateway.
APIGEE is primary source of my understanding, then google it specifics which move in different directions.
Security is our major concern.
1 - how to make sure Secure inter process communication?
Internally, whitelisting IP's and firewalls are probably the most secure. If these servcies scale and have dynamic IP's you may have an issue with that, in which case shared secrets can work, but ned to be put in place and respected across all services. JWT's are quite good for this (similar to SAML, but not as painful), used with an authentication microservice.
Externally - tokens, OAuth2 depending on how much pain you want to go through.
2 - what will be preferred protocol rest or soap in context of private api (IPC) and public APIs (exposed to clients for e.g mobile,web and desktop)
I would use REST, SOAP is slowly becoming an antiquated standard, you can secure comms p2p by using TLS or HMAC signing.
3 - What is Role of API gateway? specially is it involve in inter process communication?
An API gateway is usually used to expose legacy APIs to the public, or to manage a large set of internal services via single amanged interface. An API gateway can also help manage tokens for clients and offer a single token for multi-service access and obfuscate the internal APIs from the external interface.
Gateways tend to also offer developer portals and some kind of self-enrollment process as well as control flows for request content (inbound and outbound).
Tyk.io is an open source API Gateway - you can see the kind of features to expect from a gateway on their home page
4 - is this possible to keep some services public and some private in micro services architecture? how to logically separate both of them?
Yes, you can with an API gateway. So long as there are no inter-service dependencies.
5 - What is major difference and pros and cons of SOA and Micro SOA?
I think one is a subset of the other, SOA tends to be interconnected with a messaging structure like an ESB, but micro-SOA will bhe even more specialised and may not use an ESB.
I wanted to know how to can i protect a resource on a webserver using REST API.Like for example i want to access http://www.xyz.com/folder/impresource.doc but before accessing that i have to be authenticated. The thing is i am try to create a simple mobile client to authenticate with a rest service and then be able to access the resource.
I would appreciate a good example explaining how it can be done Thanks :)
It would be nice if i could get an example in php.
You implement a web service (be it REST, or be it SOAP) in some programming language (for example, Java or C#) running in some "container" (for example, IIS/.Net or Tomcat).
The layer below REST (for example, the C# code you're using to implement your IIS/.Net/SOAP web service, or the Java code in your .war) is the layer where you want to write any custom access code.
Alternatively, some vendors (for example, Amazon S3) have already done this for you:
http://aws.amazon.com/s3/faqs/
Other vendors (such as Microsoft) give you a way to use their authentication infrastructure with your web service:
Secure REST Service Microsoft Azure AppFabric
In java you can use a servlet filter, which will send an error code if it does not find an authentication object in the user session and if authenticated let the request handling proceed. A very popular implementation of this approach is Spring security[http://static.springsource.org/spring-security/site/tutorial.html]