2

When should we use API Proxy against API AutoDiscovery. After implementing both, I found AutoDiscovery can also apply policies, analytics which API Gateway does, only thing is I cannot use a different url if using AutoDiscovery. Main advantage of API Proxy would be if my Gateway application and Mule Implementation Project is in different subnet, so if we are my Gateway server is compromised, no one can get to my implementation network.

But if both interface and implementation is in the same network, and purpose is just to call a REST Endpoint, should we not go with API AutoDiscovery.

Problems with Mule API Gateway Proxy

  1. No defined way of Exception Handling, if we are not able to reach the Implementation Server.
  2. No defined way of moving the Proxy Application across environments (CI/CD)
  3. Extra HTTP Hops, can be acceptable if the above 2 issues have a defined way

Mule API AutoDiscovery

  1. Since this is in the Mule Application, standard Exception Handling.
  2. CI/CD is defined as it is the Mule Implementation Project.
  3. No Extra HTTP Hop.
  4. Only thing here is, we cannot change the implementation URL, that is only tightly coupled thing.

Can someone provide insight on when should we go for API Gateway vs AutoDiscovery. Also currently is there a way of doing Exception Handling in API Gateway Project and also CI / CD ?

user4338724
  • 91
  • 2
  • 7

1 Answers1

0

API Autodiscovery is required if you plan to apply/unapply a policy to a particular endpoint, and/or take advantage of usage statistics in the context of API Platform. Api Autodiscovery is kind of metadata that links a HTTP(s) listener to its counterpart API version on API Manager.

For example:

    <api-platform-gw:api id="api.basic.path" apiName="My API" version="1.0.0" flowRef="basic.path">
    </api-platform-gw:api>

    <flow name="basic.path">
        <http:listener config-ref="a.http.config" />
        <set-payload value="Endpoint successfully called." />
    </flow>

Autogenerated Mule Proxies do have autodiscovery defined. You can also develop your own project and define the corresponding autodiscovery either by using the Studio UI, or handling the XML config directly.

The proxies are mean to be used in the case that your implementation backend is not a Mule application (for example, an existing REST based API hosted in a Tomcat server). You can enrich the logic with custom exception handling among other things on the Mule side. If you'd like better exception handling on the implementation backend, you will have to implement it there.

If your implementation backend is a Mule based application, using a proxy is not required. For most use cases, adding the corresponding autodiscovery element in the configuration file will do the trick.

Nahuel Dalla Vecchia
  • 125
  • 7