Data structure overview


#1

Imported Google Group message. Original thread at: https://groups.google.com/forum/#!topic/tyk-community-support/oJ96Eb9psc0 Import Date: 2016-01-19 21:19:01 +0000.
Sender:[email protected].
Date:Thursday, 30 July 2015 06:32:27 UTC+1.

Is there an ER diagram or something similar that someone has put together showing the API data structures (and how they relate) in one place? Thinking of writing a client management app and just checking before doing it myself.


#2

Imported Google Group message.
Sender:Martin Buhr.
Date:Thursday, 30 July 2015 08:20:04 UTC+1.

Hi David,

Not that I know of, there are some interesting support projects out there, such as this swagger definition, which should allow you to generate an SDK.

Wither regards to ER, there’s no diagram, but it’s all quite loose. There are four key IDs that get used across the core gateway:
API ID - this identifies the API Definition
ORG ID - this identifies an organisation, and embedded in API Definitions to indicate ownership, but is not enforced in the gateway, only the dashboard (more on that below)
TOKEN - A token is used to access APIs, tokens can belong to an ORG, the object has an embedded ORG ID
POLICY ID - TOKENS can have policy IDs applied to them, policies are essentially templates which overwrite some elements of a TOKEN
Within the gateway’s REST API, this is all there is to it at it’s most basic level (OAuth a little more complex).

In the Dashboard, there are stronger relationships that are enforced, and it has a much more complex model, since APIs have an internal ID (DB) and a gateway reference ID (The API ID) as well as all the extra features that come with it.

In the above set of IDs, ORG IDs are not even respected unless there is an organisation-wide quota in place, both API IDs and ORG IDs are also free-form as some users want to provide or align IDs with their internal systems.

Would be more than happy to support you on this, just email me directly (just reply to this message), can give you more insight into how stuff is structured and any quirks.

Cheers,
Martin


#3

Imported Google Group message.
Sender:[email protected].
Date:Thursday, 30 July 2015 08:20:04 UTC+1.

Hi David,

Not that I know of, there are some interesting support projects out there, such as this swagger definition, which should allow you to generate an SDK.

Wither regards to ER, there’s no diagram, but it’s all quite loose. There are four key IDs that get used across the core gateway:
API ID - this identifies the API Definition
ORG ID - this identifies an organisation, and embedded in API Definitions to indicate ownership, but is not enforced in the gateway, only the dashboard (more on that below)
TOKEN - A token is used to access APIs, tokens can belong to an ORG, the object has an embedded ORG ID
POLICY ID - TOKENS can have policy IDs applied to them, policies are essentially templates which overwrite some elements of a TOKEN
Within the gateway’s REST API, this is all there is to it at it’s most basic level (OAuth a little more complex).

In the Dashboard, there are stronger relationships that are enforced, and it has a much more complex model, since APIs have an internal ID (DB) and a gateway reference ID (The API ID) as well as all the extra features that come with it.

In the above set of IDs, ORG IDs are not even respected unless there is an organisation-wide quota in place, both API IDs and ORG IDs are also free-form as some users want to provide or align IDs with their internal systems.

Would be more than happy to support you on this, just email me directly (just reply to this message), can give you more insight into how stuff is structured and any quirks.

Cheers,
Martin


#4

Imported Google Group message.
Sender:Martin Buhr.
Date:Thursday, 30 July 2015 08:20:44 UTC+1.

  • show quoted text -