enter image description here
Do they each have a specific purpose? Is one better suited than the other for a particular task?
They are two different distributions and serve different purposes.
API Gateway- It has specific features to communicate to Anypoint Platform to manage APIs, apply runtime policies, send analytics, track APIs.
Task- For deploying your proxy API Application
Mule Server- Mule server is the runtime you use for your integrations.
Task- For deploying your actual implementation API Application
Since Mule runtime version v3.8.0, both are one and the same. This means that since that version, the runtime is shipped with API Gateway capabilities, and there is no more API Gateway specific distributions released. To enable API Gateway capabilities, if you have the correct entitlement, you only need to specify your organization credentials or environment credentials (this last, it is only applicable to Mule 4 or newer).
API Gateway capabilities are the only ones who "know" how to apply/un-apply Anypoint Policies and generate Analytics info, among other things.
For runtimes released before v3.8.0, the only way to leverage those capabilities was to use API Gateway distribution. For example, API Gateway v2.x is based on Mule runtime v3.7.x.
Related
I´m interested in using the store and the developer portal. In some cases I want to integrate third-party gateway like kong.
The documentation from WSO2 API Manager 2.x says:
- Components usable separately: developer portal can be used to catalog
APIs deployed in third-party gateways
(https://wso2.com/api-management/features/)
Do you have more information about that feature and how to configure it?
Technical this is feasible but requires some work. I've found that someone did it with Intel Expressway Service Gateway.
You would need to implement a custom handler in WSO2 and connect it with Kong. But as the features might differ, the UI may not perfectly fit.
Besides than offering extension points, WSO2 has no real interest in supporting this as the API Gateway is the core component and all of their business models are based on it.
I have a mule service, named IS, deployed on mule runtime and proxied on API gateway. I'd like to set up different policies to the IS and its proxy service. How can I do it?
My environment:
Mule runtime: 3.7.4
Mule API gateway: 2.1.1
The following are two valid and equally correct solutions that you can choose from, taking into account that your implementation API is a Mule app:
Create an API on API Platform
Solution A:
Configure the autogenerated proxy to use your implementation API URL
Deploy the proxy to a correctly configured API Gateway/Mule runtime
>= v3.8.0
Apply one or more policies to the tracked proxy
Solution B:
Add autodiscovery to your implementation API, using the same API
name and API version name than your already created API on API
Platform
Deploy the impl app to a correctly configured API
Gateway/Mule runtime >= v3.8.0
Apply one or more policies to the tracked implementation app
With solution A, you have to make sure that your implementation app is only accessible by the proxy app (eg with a firewall).
If your implementation API would not be a Mule app, then Solution B would not be possible.
We can create endpoint with a proxy or select Basic endpoint if you create your API outside API Manager, for example, you created the API using Mule ESB. You don’t need a proxy in this case. So policies will be applied to API. For more details go through the link.
https://docs.mulesoft.com/api-manager/setting-up-an-api-proxy
If you're using Mule runtime v3.8.x, and if the service is an HTTP/S listener, you can actually make it auto-discovered in the API Manager and have policies applied directly on it, even if the mule config is not generated using APIkit.
https://docs.mulesoft.com/api-manager/api-auto-discovery
Choose the flow that you want the API Manager to manage and apply policies.
Do note that you will need to have to right entitlement (API Gateway) in the Mule Runtime license and that it has the right Anypoint Platform Client ID/Secret pairs configured in the wrapper.conf. The IDs should be automatically configured if you've added the Mule Runtime server in the Anypoint Runtime Manager.
Here is my solution to apply policy to proxy service:
Create a new API using proxy service's url
Apply policy to API created in step1
Can anyone confirm this is the correct way?
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 would like to know if deploying APIs designed using RAML and API-kit in the studio on Mule Enterprise Server for ESB ver. 3.6 is a good idea?
Our organization is interested in using Mule ESB 3.6 for integrations and we thought of recommending using RAML and API-kit for REST API design and development. We are not interested in any Gateway features but would like to leverage RAML for API definition.
Has anyone experienced any issues if we go for a Mule ESB 3.6 Enterprise and deploy these REST APIs designed using API-Kit and RAML there? Is this design approach specifically meant for the API Gateway which is part of the Mule Any-point API Product offering?
API Gateway (AGW) is a superset of Mule EE. RAML and APIKit are not tightly coupled to API Gateway or Mule ESB but can work in either of them. In the case of AGW, APIKit comes bundled with it, while with Mule ESB you have to provide the jar yourself or develop your APIKit project on Mule Studio (using the APIKit Mule Studio plugin) and export the project from Mule Studio when ready.
The advantage of using AGW is that you can develop your APIKit project as usual, and then be able to apply-unapply high end policies to it at runtime (OAuth security, XML Threat protection, IP Blacklisting, etc, etc).
I have used this REST API using RAML for my client. They didn't face any issues and it's working perfectly. And it's easy to implement.
I see no problem in doing what you are suggesting. Gateway and such are services build on top of Mule and RAML technologies -- if you choose not to use them you'll just lose the features they offer but again RAML, Mule, and APIkit work just fine on their own!
In latest version of mule brought many features like api auto discovery and there is no separate gateway and runtime they have been combined together as a single component.
Api auto discovery allows us to apply policies on top of original implementation api.
you can create proxy for the original implementation and policies can be applied on the proxy layer which is in gateway.
am new to API LM & confused about Building APIs using tools such as apigee, 3scale, mashery, mulesoft, TIBCO APIX etc
all these years , I know API is all about a language's API or SDK which you use to write/build code/application to solve a business problem. Say Java API or J2EE API etc
Do I have to build my own dataservice using my application/system and expose it as a service (WS/REST) and use the above tools (apigee, 3scale, mashery, mulesoft ec) or does these tools allow a developer to Build APIs from the scratch?
In other words, do I create your own application within your enterprise (be it Java based, DB or a .Net service or a Web App hosted on weblogic) and expose it as API for B2D or DX (with auth, analytics, portal, developer access) which is called as "build an API"?
When using Apigee Edge, you must expose your backend as an http/https endpoint first. Then, you can add security, caching, quota, and many other features to your API facade. When using the Apigee-127 product, you can create an entire backend using Node.js locally and then deploy it to run in the cloud.