You have found an old pageVisit the new Docs
This document outlines how Tyk can be used to bind APIs to domain names using internal domain handling.
It is often confusing to try and understand how Tyk handles URL routing to grant access to upstream APIs, we’ve made sure that the way Tyk handles inbound requests is as flexible as possible in order to allow for as many styles of configuration as possible. Here are a few scenarios which explain how the gateway can be used to route traffic through the proxy.
Tyk uses something called a
listen_path in its API Definitions to route requests to the appropriate upstream API, so if you had a microservice architecture with three api’s (
api3.yetanotherserver.com lets call them), then Tyk could be set up to proxy those three apis in a few ways, here’s a few scenarios:
Note the upstream API URL’s can be arbitrary, so long as the base path is correct.
If you use the Tyk Gateway application on it’s own – this means not using the host manager or binding domains to APIs, and just letting tyk act as a proxy, assume tyk is running on
tyk.mygateway.com, out of the box it will do the following when you add APIs to it’s configuration, for conveniences sake, we are assuming you are setting the
http://tyk.mygateway.com/api1/* -> api1.someserver.com/* http://tyk.mygateway.com/api2/* -> api2.anotherserver.com/* http://tyk.mygateway.com/api3/* -> api3.yetanotherserver.com/*
This scenario suits a microservice architecture well, since the listen paths are configurable you can set up a unified URL structure for your whole API group as a whole. Remember that API policies and keys can grant access to multiple upstream APIs with global rate limits, so one key can now be granted access to all three APIs.
Tyk has multiple levels of domain management that can be added to a nodes, these are bound to each API entry in the Tyk routing table:
Bind the gateway to a domain – by default Tyk will react to any inbound requests, if you set up a domain name for the host name, then this will form the basis of all API maps, this will take the form of:
Bind individual APIs to their own domains – you can add a domain field to your API definition, this will then have Tyk only route to domain + listen_path configuration of this set up, multiple APIs can use different listen_paths to be maped to the same domain:
- gateway-domain/listen_path_1 (for unmapped APIs)
Bind the Tyk API to a segregated domain – This is an additional security feature, so in addition to the above, it is possible to set a domain name for the control API only.
Dashboard domain – it is possible to bind the dashboard to a specific domain
Portal domains – Any organisation that has their CNAME set (and CNAME Enabled) in their organisation object (see the Advanced Admin API) will bind the portal to that specific domain.