Your API addresses

If you need to set several DNS for you APIs on API Connect, then that's your post.
Here we'll discuss the use of the 0.0.0.0 IP, the Gateway Extensions and an example to expose an API in to several IPs/DNS

Let's say that we are working for SuperAirLines, an imaginary airline. As it's a big company they have some subsidiaries as SuperLowCost for a cheaper (and less comfortable) flights. Both uses the same API to standardize the user experience and lower costs, but each brand has its own webpage and SuperAirlines doesn't like to mess up with SuperLowCost so the API must response on the same DNS name that the webpage; this way everything will seem to be separated.

Sometimes it's enough if you point both DNS to the same IP, as it would be on the external website: the browser will call the same IP and port even the name that it gets is different, so it will be calling the same API. Good.
If that's your case, congratulation, it's almost done. Tell the DNS team to set the same IP and don't forget to use the SNI with all your names when setting the gateway service.

If you're not so lucky, you'll need different IPs under those DNS. That would be the case on internal calls; imagine that each brand has its own network and they must enter to the DataPower (the API Connect gateway) from different eth ports or VLANs; that makes impossible to use the same IP for both connections. 

As you might know, when you set the gateway for installation you must provide an IP, but it's one and only one IP. Then when you set the gateway service, you can set several DNS but not different IPs.
So, if I can set only one IP, you might think into a magical IP that will make it listen on all of them: the 0.0.0.0
(Spoiler: do not use the 0.0.0.0, continue reading, please).

The 0.0.0.0 IP

Why it's so special? This IP is a mean of saying "all the DataPower IPs", included the management one.

• Security: You're exposing that service on each the IP's. You can't disable one specific IP.
• Resources: You're blocking that port on all the IPs, so it can't be used by other services.

Let me underscore it: DO NOT USE THE 0.0.0.0 IP UNLESS YOU HAVE NO OTHER OPTION.

That special IP shouldn't be used on a production environment, so if you see it on your systems, check if you can change it. It come as the predefined IP for the ssh, web management and some other services for convenience, so you can use those services asap to configure the appliance, but once again, change it to use only the management IP or Host Alias to do not expose the management services on the service IP.

Exposing an API on several IPs

Going back to our case, if I should not use the magical IP that let me publish the APIs on all my interfaces, how can I set the same service on several IPs? 

Let's understand how API Connect works regarding the APIs exposure. Basically, it gets the data introduces on the Manager subsystem and propagate it to the DataPower, so one would think: "ok, once it's propagated, we can add a new FSH (Front Side Handler) to the APIGW (API Gateway)".
Even you can do it, and it will work at first, that's not a good idea. Keep in mind that any change on API Connect must be done thought the Manager, otherwise you can lose those changes. I don't want to mess around why is this so I'll say that it's the Kubernetes philosophy; you should be able to create a new gateway subsystem (DataPower) from scratch only with the manager information.

Specifically, in this case you'll lose the manual changes when you publish or delete an API on this same catalog.
Fortunately, API Connect have some mechanism to create additional data on DataPower, and it's called "Gateway Extension"; with that we can create or modify any configuration without lose it once it's reloaded, because the manager will send the extension in addition to the changes that it needs to propagate.

Gateway extensions

The Gateway extensions are well explained on the Knowledge Center, take a look before continue.
The basics are:

• It's a collection of CLI commands
• You can control the order when those commands are executed with the prefix on your filename
• You can create several files if necessary

Tip: In addition to the CLI guidelines, if you have a development environment you can save you changes manually on the DataPower and look at the .cfg file of that domain on the config folder to check see how those changes are translated to cli commands.
Tip: If the object that you intend to change already exist, you don't need to create it and set all its parameters, only change the necessary parameters.
Tip: You can see the current cli commands on the temporary folder. You can add a new file or to override an existing one.

Attached you can see the extension for this example: We overrides the file "10.gateway_front-protocol.cfg" because the FSH definitions are on that file; it might be possible to create a new file "11.gateway_extra-front-protocol.cfg" instead with only the new FSH, that's your choice. We also modify the APIGW on the file "35.addfsh.cfg" to add those FSH. Be sure that the APIGW name used on our file is the very same that the created by the manager, because we're modifying an existing object; if you use a different name, you'll be creating a new object that will not be used.
Note that one of those FSH could exist, depending how did you defined the API on the Manager, if so, the name must match in order to overrides the object, otherwise you'll have two FSH on the same IP/port and one of them will be down.

Of course, DataPower extensions can be used to create any configuration, even entire domains! But try use the API Connect out-of-the-box capabilities whenever it's possible to ease the maintaining.

An alternative: the Gateway services

If you're on VMWare or Physical DataPower, there is an alternative: to split the current DataPower appliance in to several Gateway services. Right now it's not possible to hold multiple domains on a DataPower over Kubernetes/OpenShift (it would be opposed to the Kubernetes philosophy), so if that's your case this alternative is only possible creating more DataPower pods, that means more CPU hold (not necessary more CPU usage), so check your licence before proceed.

The approach with the gateway extension will publish all the APIs of that catalog in all the desired IPS, but you can't publish some APIs on some IP and some others in another one. In addition, if you need to split your installation in to several DataPowers, it can be easily done with the gateway services approach.

To create several Gateway Services is very straightforward, as you must add at least one on the installation, simply create and add as much services as you need.

Create a new DataPower domain and follow the domain configuration guide for API Connect; you'll need one domain per IP address where you'd like to publish, and that domain can be created on the same DataPower or in a different one. Add all the gateway services to your topology as described on the guide.

Optionally you can set the gateways to use by default: on the CMC go to Settings and then to Catalog Defaults, edit and add the gateways that will be automatically added when you creates a catalog (including the Sandbox catalog when you creates an organization). Otherwise you must to manually add the gateways for each catalog.

When the API is published in the catalog you can choose on which DataPower service/s it will be published, and thus, on what IP it will be exposed.