Override API definitions target_url for local dev

Support Installation and Deployment
,
1

I’ve got a Dockerized version of Tyk gateway set up running. It has a couple API definitions. I’m wondering about ways to organize this so that local dev can happen smoothly.

Is there a way to take a production API definition and override the target url?

For example taking something like:

"proxy": {
    "listen_path": "/us/",
    "target_url": "http://service.mycoolsite.com/api/v1/",
    "strip_listen_path": true
},

and overriding the target_url to something like:

"target_url": "http://host.docker.internal:8082/api/v1/"

I was looking at the middleware and url rewrite options, but it doesn’t look like it’s possible with those. Perhaps I’m missing something.

The goal here is to not have two sets of API definitions which may end up diverging and causing “it works on my machine” issues.

2

Split horizon DNS or an entry in the hosts file?

3

Thanks for the suggestions. Not sure that would work in our case. Hosts file would make the production site in accessible from the dev machines. Haven’t worked with split horizon DNS, but we are all remote so sounds like that’d be a DNS for each dev and would also block the prod site.

Was hoping I was just missing something obvious. It’s hard to understand how this use case hasn’t been addressed since it feels like it would be a pretty common one, but maybe I’m wrong?

4

Hi,

The URL rewrite middleware can help with this. Have a look at this page for more info. There are a number of advanced options including metadata read from an associated policy.

Cheers,
Pete

5

Thanks Pete!

I suspect I’m meant to be looking at triggers. Looks promising. One note, I believe the example is improperly structured:

"triggers": [
  {
    "on": "all",
    "options": {
      "header_val_matches": {
        "X-Enable-Beta": {
          "match_rx": "true"
        }
    },
    "session_meta_matches": {
      "beta_enabled": {
        "match_rx": "true"
      }
    }
  }
    "rewrite_to": "https://beta.upstream.com/feture"
  }
]

Looks like "header_val_matches" is missing a closing bracket. And maybe there’s a extra closing before rewrite_to?

6

Maybe it would be easier to ask if this is what’s expected:

"url_rewrites": [{
    "triggers": [
      {
        "on": "all",
          "options": {
            "header_val_matches": {
              "X-Enable-Beta": {
                "match_rx": "true"
              }
            }
          },
          "rewrite_to": "https://api.example.com/v1"
      }
  ]
}],

Also, is there anything need in the conf to get url_rewrites working. I can’t seem to get the trigger to fire.

I’m hoping that it doesn’t require this bit

      "path": "/foo/bar/baz",
      "method": "GET",
      "match_pattern": "/foo/bar/baz",
7

Hi,

Thanks pointing out the error in that example. I’ll get it fixed.

I’m afraid it does require those bits, that might be why its not working for you.

"url_rewrites": [
          {
            "path": "/",
            "method": "GET",
            "match_pattern": "/",
            "rewrite_to": "",
            "triggers": [
              {
                "on": "all",
                "options": {
                  "header_matches": {
                    "X-Enable-Beta": {
                      "match_rx": "true",
                      "reverse": false
                    }
                  },
                  "query_val_matches": {},
                  "path_part_matches": {},
                  "session_meta_matches": {},
                  "request_context_matches": {},
                  "payload_matches": {
                    "match_rx": ""
                  }
                },
                "rewrite_to": "https://api.example.com/v1"
              }
            ]
          }
        ]

Will a solution that rewrites on a header value work in your case?

Cheers,
Pete