Contact Us 1-800-596-4880

Naming the Application Reference

CloudHub requires a unique application name regardless of the region where you deploy the API. You can, for example, add the region name to the application name to ensure uniqueness. For example:

test-customers-eu

test-customers-na

By default, APIkit adds a base path to each API, namely /api. The final URL of the APIs deployed on CloudHub is:

http://test-customers.eu.cloudhub.io/api/customers

http://acceptance-customer.eu.cloudhub.io/api/customers

Running Multiple Versions of the Same API

To run multiple versions of the same API simultaneously, deploy each API implementation using an unique name. For example, add the version number for uniqueness:

test-customer-v1.eu.cloudhub.io

test-customer-v2.eu.cloudhub.io

The final URL of the APIs deployed on CloudHub is:

http://test-customers-v1.eu.cloudhub.io/api/customers

http://acceptance-customers-v1.eu.cloudhub.io/api/customers

Dropping the environment prefix for production is a MuleSoft best practice. For example:

http://customers-v1.eu.cloudhub.io/api/customers

You can setup desired URLs for each application on CloudHub by using a custom load balancer. For instance, you can configure http://api.yourcompany.com/customer/v1 to point to this URL:

http://customers-v1.eu.cloudhub.io/api/customers

Configuring the Path for Deployment Onsite

By default, APIkit generates a listener having a base path of /api. A different application deployed on the same server attempts to listen on the same context, for example http://server:port/api/, which causes a conflict.

To avoid such a conflict, configure each Mule application using a different base path. For example:

/api/customers

/api/products

If multiple versions of the same application need to run on the same server, add a version designator to the base path. For example:

/api/customers/v1

/api/customer/v1

Because each server belongs to a different environment, there is no need to include the environment, such as /test or /dev, in the base path.

Avoid hard-coding URLs in base path. Use different property files for different deployments:

`dev-on-prem properties: base.path=/api/customers/v1` and `dev-ch properties: base.path=/api/*` highlighted.

You can configure a custom load balancer to adjust URLs. For example, http://api.yourcompany.com/customer/v1 can point to http://server:port/api/customer/v1.

Using a Load Balancer

If your API implementation involves putting a load balancer in front of your APIkit application, configure the load balancer to redirect URLs that reference the baseUri of the application directly. If the load balancer does not redirect URLs, any calls that reach the load balancer looking for the application do not reach their destination. For example, you deploy an APIkit application to myapp.mycompany.com, and then add a load balancer at www.exampleloadbalancer.com. A call to the API arrives at www.exampleloadbalancer.com and the load balancer redirects the call to myapp.mycompany.com to get a response.

When using a load balancer, set the keepRamlBaseUri attribute as described for using APIkit with a reverse proxy.