Imported Google Group message.
Date:Wednesday, 18 February 2015 10:50:01 UTC.
We're actually contemplating a developer portal - though the issue is making it generic enough for a wide range of use cases.
If we built one, looking back, we'll probably not integrate it into the dashboard and instead start a new open source component. We would definitely be interested in getting some help around this, as we're hammering out requirements, so far we have a few ideas around features, very high level for now:
View description of all public APIs
Methods, endpoints and parameters
Send sample requests from the docs
Signup / Login
Quotas and limits for each API key
Manage user profile
Manage user subscriptions (add / remove)
Manage API Listing
Group Key Template (One key for many APIs) - Single Quota
Per-API Key template (One key per API) - Multiple quotas
Payment redirect URL
Subscription inactive API endpoint
Subscription active API endpoint
We would use the Advanced Management API to get the currently live API's for an organisation, these would then map against entries in a database, this way documentation, content etc can be developed against an inactive API (Tyk's API endpoint only shows loaded API's IIRC, not inactive ones)
Data structures for things like user profiles, API intros, home page etc would be loose interfaces, with only some fixed fields, that means that implementers can create their own fields (maybe as JSON configuration files) which get exposed to templates so it's really flexible. This makes the backend MongoDB, but since the dashboard uses it, this should be ok.
Templates would be Golang based, so pretty flexible, and we make the base, default template out of Bootstrap so that it can be themed and adapted easily.
The only prescriptive part of the portal data structures would be the API documentation bit, where we could use something similar as we do with the designer in the dashboard to build out an endpoint map. I'm reluctant to use the actual definition as they can, by design, be incomplete so that the whole API doesn't need to be defined resource by resource.
We've added in a few endpoints to activate and deactivate profiles (this would just chain out a request to the Dashboard API to deactivate a key), with the view that some integrators may wish to charge for plans, with either bundled keys (multiple API's can be accessed with one key, this applies a single quota though), or bundles where a separate key is provided per API, but they can be bundled together as a plan, this way there are multiple quotas per key. I think this bit is the one we're struggling with defining properly as it's difficult to make this bit generic enough, I'd like to make it as simple as possible TBH.
Longer term we can build in payment integrations with things like Stripe or Paypal so it's enabled out of the box. But for now I'm happy to hand-off to a third system using a redirect.
Would really appreciate your (and the rest of the community) thoughts on this
- show quoted text -