Fork me on GitHub

{"Tyk API Management"}

Tyk API Management

This is an APIs.json index for the APIs I'm tracking over at Tyk. It is meant to provide a single collection of their API management APIs, while also providing individual APIs.json files defining each API's operations, and surface area.

The entire API index is available under the _data folder for the project's Github repository, providing a machine-readable index of the GSA APIs for use across my systems. It provides a single forkable repository that acts as a machine-readable discovery index of APIs operated across the GSA, that anyone else can also put to use.

To help me make sense of their APIs, I got to work creating a basic Liquid-driven listing of all the APIs I have indexed in the _data/api-commons/ folder of this API index. Each API has it's own folder, APIs.json index, and OpenAPI Spec--this is the result of those machine readable index, with a little HTML polish to make it easier on the eyes, and for human consumption.

Tyk (view APIs.json)

An open source, lightweight, fast and scalable API Gateway. Set rate limiting, request throttling, and auto-renewing request quotas to manage how your users access your API. Tyk supports access tokens, HMAC request signing, basic authentication and OAuth 2.0 to integrate old and new services easily. Tyk can record and store detailed analytics which can be segmented by user, error, endpoint and client ID across multiple APIs and versions. Integrate your existing or new applications with Tyk using a simple REST API, Tyk even support hot-reloads so you can introduce new services without downtime.

Tyk API Management Paths Available (OpenAPI Spec)
  • /tyk/apis/ -- Get APIs [GET] - Gets a list of *API Definition* objects that are currently live on the gatewayn
  • /tyk/apis/ -- Create API [POST] - Create an *API Definition* objectn
  • /tyk/apis/{apiID} -- Delete API [DELETE] - Deletes an *API Definition* object, if it existsn
  • /tyk/apis/{apiID} -- Get API [GET] - Gets an *API Definition* object, if it existsn
  • /tyk/apis/{apiID} -- Update API [PUT] - Updates an *API Definition* object, if it existsn
  • /tyk/health/ -- Check Health [GET] - Gets the health check values for an API if it is being recordedn
  • /tyk/keys/ -- Get Keys [GET] - Gets a list of *key* IDs (will only work with non-hashed installations)n
  • /tyk/keys/create -- Create Key [POST] - Create a new *API token* with the *session object* defined in the bodyn
  • /tyk/keys/{keyId} -- Remove Key [DELETE] - Remove this *API token* from the gateway, this will completely destroy the token and metadata associated with the token and instantly stop access from being grantedn
  • /tyk/keys/{keyId} -- Add Custom Key [POST] - Add a pre-specified *API token* with the *session object* defined in the body, this operatin creates a custom token that dsoes not use the gateway naming convention for tokensn
  • /tyk/keys/{keyId} -- Update Key [PUT] - Update an *API token* with the *session object* defined in the body, this operatin overwrites the existing objectn
  • /tyk/oauth/authorize-client/ -- OAuth Authorize Client [POST] - The final request from an authorising party for a redirect URI during the Tyk OAuth flown
  • /tyk/oauth/clients/create -- OAuth Create Client [POST] - Create a new OAuth clientn
  • /tyk/oauth/clients/{apiId} -- OAuth Get Clients [GET] - Get a list of OAuth clients bound to this back endn
  • /tyk/oauth/clients/{apiId}/{clientId} -- Delete Client [DELETE] - Delete the OAuth clientn
  • /tyk/oauth/refresh/{keyId} -- Invalidate Key [DELETE] - Invalidate a refresh tokenn
  • /tyk/reload/ -- Reload Gateway [GET] - Will reload the targetted gatewayn
  • /tyk/reload/group -- Reload Group [GET] - Will reload the cluster via the targeted gatewayn

Liquid makes it easy to work with any JSON or YAML in the _data folder, treating this as a data source. Using Liquid I can do almost anything I can do with PHP, Python, Ruby, Node.js, and other server-side languages--the big difference here, is there is no hosting necessary, it all runs on Github. You don't need database backend, or a server to host website--it is all on Github. If your repo and data is public, it doesn't cost you anything to operate--offloading hosting and bandwidth costs to Github for all your open data, and API projects. This is big deal if you are managing a lot of public data. You can find a gist of this liquid script here.

Currently, the biggest benefit of have APIs indexed in this way is when it comes to documentation. I can use Liquid to create my own HTML documentation, or I can also put to work other API documentation solutions like Swagger UI or Redoc. Additionally, APIs.json allows you to also include other relevant information like where to sign up for an API key, and the terms of service for using an API. OpenAPISpec describes the APIs, APIs.json defines the supporting operations around those APIs, and provides us with a nice machine-readable index of everything.

Eventually, having our APIs defined in this way helps each index become an engine for every stop along the API and application lifecycle. The APIs.json can act as entry point for integration with any single, or multiple APIs, allowing us to then generate SDKs, testing scripts, monitoring, discovery, and any number of critical needs we have throughout the life cycle of our APIs and applications. This will all take time, but we have to start somewhere.

APIs.json Autocomplete

I want to be able to create autocomplete tooling that is driven from this projects APIs.json, providing access to the paths, verbs, and tags contained within the APIs.json collection.

Path:

Verb:

Tags:

This tool allows me to aggregate and provide access to a list of paths available across all the APIs indexed within this collection--something that can be used across the API design process. You can find this tool as a Github Gist, or available within the Github repository for the project.

APIs.json Tag Cloud

Using the APIs.json for this project, I wanted to get a visual summary of what resources are available to me across all the APIs indexed here. Tagging is an important part of defining an API, so I wrote a little tool to aggregate all the tags, across all APIs indexed, and show as a tag cloud visualization.

The more APIs indexed, the more tags that show, and the bigger some tags will get. Showing a quick snapshot of all the resources available, in a single, easy to digest visual. You can find this tool as a Github Gist, or available within the Github repository for the project.

APIs.json List Paths by Tag

Next I wanted to think differently about how I list APIs indexed in the APIs.json for this project. At the beginning of this story I was showing all the available paths grouped by API. I wanted to look at things a little differently and just mix all the available paths together, and group by tag--giving me a much different look at the resources available in this API index.

This gives me a new way to look at the resources across providers, or different groups. I always find it useful to hide the information about the company, agency, or group behind an API--I find the APIs, their available paths, parameters, and other details to be a more truthful look at what is going on. You can find this tool as a Github Gist, or available within the Github repository for the project.

This is just a sampling of what is possible when API definitions are available. When you have machine-readable OpenAPI Specs available, indexed using APIs.json, a whole new world of tooling and services emerge. This landscape is already picking up momentum with the growith in adoption of OpenAPI Spec, but with each new resulting definition available in the format, and tooling or service provider that emerges, things are picking up speed monthly in 2017.

With the API definitions in this collection you could now generate SDKs using APIMATIC, monitor your APIs with API Science, and test them using Runscope. This is just small taste of wat you can do once you have API definitions. Now we just need to keep doing the hard work to make sure our APIs are as defined as they possibly can using OpenAPI Spec, and indexed individually, and in collections using APIs.json.

You are welcome to make any changes to the JSON files for this project, or leave any feedback via the Github issues.