API slug vs Listen path


#1

Imported Google Group message. Original thread at: https://groups.google.com/forum/#!topic/tyk-community-support/VTsrp4g9W74 Import Date: 2016-01-19 21:24:39 +0000.
Sender:Tor Inge Skaar.
Date:Friday, 18 September 2015 15:07:29 UTC+1.

In the API Designer in the Dashboard, you can specify an API slug for the new API you’re creating. Now, I was under the impression that you could leave the auto-generated listen path as is and Tyk would also listen for the slug. I.e. that you could use the slug in the request URI instead of the API ID.

API Name: “Test API”
API Slug: test
Target URL: http://somehost:someport
Listen Path: /258dfd04a6fe423c72b65ccac1b0b84a/

But when I try this…

http -v tykgw.example.com/test/resource/1
GET /test/resource/1 HTTP/1.1
Accept: /
Accept-Encoding: gzip, deflate, compress
Host: tykgw.example.com
User-Agent: HTTPie/0.8.0

HTTP/1.1 404 Not Found
Connection: keep-alive
Content-Length: 19
Content-Type: text/plain; charset=utf-8
Date: Fri, 18 Sep 2015 13:41:57 GMT
X-Content-Type-Options: nosniff

404 page not found

…it doesn’t work.

Now, if I change the Listen Path…

API Name: “Test API”
API Slug: test
Target URL: http://somehost:someport
Listen Path: /test/

…and rerun my test…

http -v tykgw.example.com/test/resource/1
GET /test/resource/1 HTTP/1.1
Accept: /
Accept-Encoding: gzip, deflate, compress
Host: tykgw.example.com
User-Agent: HTTPie/0.8.0

HTTP/1.1 200 OK
Connection: keep-alive
Content-Length: 123
Content-Type: application/json; charset=utf-8
Date: Fri, 18 Sep 2015 14:00:09 GMT
Server: gunicorn/17.5
X-Ratelimit-Limit: -1
X-Ratelimit-Remaining: 0
X-Ratelimit-Reset: 1442583650

{
“id”: 1,
“text”: “Hello”
}

…it works as I want it to work.

Have I misunderstood the function of the API slug vs the Listen Path?

Best regards,
Tor Inge Skaar


#2

Imported Google Group message.
Sender:Martin Buhr.
Date:Friday, 18 September 2015 15:17:25 UTC+1.

Hi,

Yeah, the api-slug is actually used by the host manager when generating templates, the reasoning is as follows:

In an environment where there are many APIs, we don’t want collisions on the listening handler (listen_path) so we auto-generate it (and actually you can make it non-editable using a configuration option so users don’t mess things up). However, it may also be the case that you are using the host manager, and that you want to use your own domain/org/api combo to build your API paths (i.e. Tyk dictates routing has to be: domain.com/listen_path, not everyone wants that, but we need a concrete implementation somewhere).

So we have the api_slug (and owner_slug in the Organisation object), these values are of interest to the host manager and can be injected into nginx templates for routing whatever domain config you want.

So for example, in the quickstart docker, we set it up so that APis run on:

api_slug.org_slug.tyk.docker

And on Tyk Cloud we set it up so that it’s:

org_slug.domain.com/api_slug

But you might want it to be:

domain.com/org_slug/api_slug

All of that is possible with the host manager, and that’s what the api_slug and owner_slug are for, they essentially get mapped to the listen_path so Tyk knows what to do. tyk only ever cares about the listen_path to do anything.

Might need to clarify that in our docs :-/

Cheers,
Martin


#3

Imported Google Group message.
Sender:Tor Inge Skaar.
Date:Friday, 18 September 2015 15:47:33 UTC+1.

Thanks for the clarification!

I guess the reason for why I’ve overlooked this is because I don’t use host manager. Nginx is running on a separate server, and both Redis and Mongo running on the Tyk GW server and bound to localhost.

But I do see the potential here with host manager.

Thanks.

Tor

  • show quoted text -