Two api definition, same listen path, different custom middlewares

Support
,
1

Hello,

I have a use case with two api definition A (POST endpoint) and B (GET, DELETE endpoints) with the same listen path (/service - they are handled by the same backend service) but I have to assign different custom middlewares (A needs certain middleware B needs different ones). The problem when issuing a GET call (GET /service - for example) is that Tyk apparently matches the first API definition resulting with a 404 NOT FOUND response. How can I handle such use case? I would prefer not to add custom logic in the middleware code or force myself to use different listen paths.

Thank you!

2

TL;DR Not possible unless protocol, domain and port are different. Not recommended unless a dashboard is present and gateway sharding is enabled

Just like a URL, an API route serves as a unique address that directs incoming requests to the appropriate server resource. It’s essential to ensure that API routes are distinct to prevent conflicts, maintain system integrity avoid potential issues. Duplicate routes can lead to confusion, performance issues, and even security vulnerabilities.

While dashboard and gateway configurations allow you to define the same listen_path for different APIs, the gateway automatically generates unique base routes for each API definition during reload or initialisation. A base route is considered unique if the following attributes differ:

  • protocol
  • domain
  • listen_port
  • listen_path

If a duplicate API is detected, the gateway attempts to resolve the conflict by appending the api_id of the API definition to the listen_path using a hyphen - as the separator. This ensures that API listen routes remain distinct to prevent collisions.

time="Jan 02 10:38:31" level=error msg="Listen path collision, changed to
/duplicate_api_definition/-f7fa46a3c20b412c54e0a63d6c4fef12"
api_id=f7fa46a3c20b412c54e0a63d6c4fef12 api_name=TestAPI org_id=653646c1d13bcc0001a557ff

To strictly enforce unique listen_paths and domains, you can disable duplicate slugs in the dashboard configuration. This ensures that both listen_path and domain are validated for uniqueness. However, listen_port and protocol are exempt from this check.

Attention
Due to the unordered nature of JSON, there’s a possibility of intermittent 404 errors
for duplicate API definitions during gateway startup or API reloads. This is because
the APIs are randomly registered, and a different API base route may be assigned.
API reloads happens when a CRUD operation is performed on the dashboard or when the
gateway hot reload API is triggered.

It’s generally recommended to avoid duplicate listen paths in Tyk deployments. If you have a specific use case that necessitates multiple APIs with the same listen_path, such as serving APIs to different gateway regions, consider using gateway sharding to handle the routing effectively.