The API Definition For The Tyk API Gateway27 Feb 2017
If you are selling a service you should have an API. It is something you hear me talk about a lot here on the blog. I push on this subject because it is important, and there are numerous API service providers out there who do not have an API or choose to not make them available. In a DevOps, continuous integration world, we need the entire stack to have APIs--making our API platforms programmatic, just like the data, content, and algorithms we are making available via the APIs we are deploying.
If you need an example of this in the wild, you don't have to look much further than my partner in crime Tyk, who have a simple API for their API gateway--no matter where you deploy the gateway, you can manage it using it's APIs. The Tyk API Gateway API provides you with a base set of paths for you to manage your gateway.
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.
The Tyk API Gateway provides a base set of API management features that can be deployed in the cloud, on-premise, or on-device. Making the key ingredients for API management programmable.
Tyk's API Gateway represents just one component in any API operation's toolbox. Tyk also provides an OpenAPI for the API gateway making things much more plug and play as part of any API life cycle--something I've made even more discoverable using APIs.json. Their approach provides a nice blueprint that all API providers should be following--well-defined APIs for all your services (open source if you can ;-).
I track on any service or tool I include in my research like it has an API. If it does have an API, I profile it like I did with Tyk. If it doesn't, I will harass them until they have an API. If you are building tools, or selling services to the API space, you should have an API, as well as provide OpenAPI and APIs.json definitions for all your goods.