Harsh criticism Johnny! But we'll take it on board, feedback has been passed to the https://tyk.io/ team, there is certainly an opportunity to adjust proportions here. As a matter of interest, which blog/article page layout do you really rate?
I think I was that emphatic because I couldn't believe anyone would want to exhibit such an obviously flawed design in public until it was fixed. I'm still confused how this would make the light of day, but I guess esthetics and usability are something learned perhaps over time?
Hmmm, but is REST so often conflated with 'just' CRUD, because that is all people really want from REST, or is it that this perception is so pervasive that people don't know what the potential is. Chicken or Egg? I'm saying Egg, but I'm not saying which that relates to :)
CRUD is easy to understand and close to the core of tasks that programmers at large need to do.
Thinking in terms of REST requires that you concern yourself about the full infrastructure. Many programmers i have met simply do not care. Super nice properties such as cacheable and discoverable are outside their domain. Most simply just want remote RPC.
Try convincing a programmer of the benefits of HATEOAS is though. It will be dismissed as too much hassle with no real benefit.
But if you look at it from a data architectural perspective everything just "clicks". Few projects are however approached from that angle.
HATEOS can be a weighty concept to get across and it never clicked for me until I read a book on it. I still think there are aspects of it that could be learned easily enough in isolation though. Understanding media types for example allows you to develop some really nice schemes for API versioning. But few people are even willing to learn that and just butcher their URLs instead.
Charging for access to your API is possible with Tyk Pro, including the free edition.
Approach:
Setup API in dashboard
Create policies for the API (encapsulate rate limit, quota, access rights into something like bronze, silver, gold, etc)
Publish policies to Developer Portal
Use dashboard to Select a custom flow for policy access approval.
Point that flow at your billing platform, stripe or whatever.
Now when a developer reaches your portal and requests access to one of your policies, you collect the data you want and hand them off to stripe to confirm payment for that policy, then the callback from stripe allows portal to issue access to the policy.
If you can install an open source Tyk gateway in your stack, you can use TLS on the Tyk Gateway to refuse HTTP outright. However, this isn't a Tyk cloud feature at present.
Hey Bob - you'll be pleased to hear Tyk took that feedback on-board. There is now very comprehensive documentation and user-guides. And true to the Open Source approach, anyone can contribute to them, the community have been great in working to improve them.
