Tyk API Designer

I was playing around with Tyk API Designer the other day and I noticed there are 2 ways to edit an API - API Designer or Raw API Definition.

  

API Designer View

Raw API Definition View

I'm not too sure you belong to which camp. I have team members who belong to both camps. The juniors will definitely prefer the API Designer view, while the seniors will go for the Raw API Definition view.

When we go to customers' sites, it's quite obvious. Customers will prefer API Designer view, while my team will most likely configure using the Raw API Definition view, especially when there are a lot of APIs to configure.


That's cool!

.

Data-model driven API - Good or Bad?

I came across this blog from Tyk - Your data model is not an API, while I was lying on my bed ready to sleep. 

To me, this is taking a dig at CA Live API Creator. :)

Very insightful article, indeed. This is coming from API consumers' (Customers) perspective, rather than from API developers.

Sometimes, we keep forgetting who our pay-masters are. This is why I keep reminding my team - they have to make our customers happy, not me.


I totally agree with the conclusion:

• Your API consumers want an API that is familiar to them, not to your implementation team 
• Your API consumers want an API that is fast to integrate for them, not for your internal team to implement 
• Your API consumers want an API that is flexible by offering capabilities to get things done, without creating lots of HTTP calls and stitching data together to achieve their desired outcomes 

Finally, it is important to remember that 5 hours saved by your team may cost 10s to 100s of hours by your API consumers. ... A great API design makes it easy for API consumers by hiding internal implementation details, leading to faster integration and happy developers.

It is definitely not easy to design an API.

From our experience with a large insurer in Singapore, we know it could take weeks to design a useful API. Sometimes, we could end up having heated arguments with our customer's application teams, because we do not agree with certain design methodology. But the end result is great! There's nothing wrong with disagreements, as long as it's for the good of the project.


.

APIs Design, Development & Management

I have forgotten where I have captured this diagram, but it really reflects the truth on the ground.

90% of APIs rely on developers to code! Of which, 60% rely on developers to create and manage their own APIs. Only a tiny 23% did developers use a proper API Management tool to create and manage their APIs.

There is still a big market for API Management tools.  :)


.

API Design & Implementation Tips

I was attending CA Partner Momentum held in Singapore this week. We had John flying in from Australia to conduct the event for us.

Some tips from John which I think are useful for field staff like us.

1. Recommend agile approach 
2. Collaborate with customer - get 1 dedicated person from customer's side to work 
3. Minimum viable product 
4. Select a simple API 
5. Generate test case first (POSTman) 
6. Use Gateway to emulate backend 
7. Share test cases with client as early as possible 
8. Show progress against test cases 
9. It's ok for customer to change their mind (embrace change - but ask for something in return) 
10. Leverage API Academy for questions around strategy

.

API Design - Initiate Optimize

In my previous blog, I talked about a customer of mine who worried about too many calls hitting her API Gateway.

As we have seen quite a number of API deployment gone live, these are typical worries. One has to treat this type of project as a Full Lifecycle API Management journey. API deployment cannot be treated as a one-off project.

The worry that the customer had is where we will usually Initiate Optimize as illustrated in the diagram above.

• Optimize the way the application requests for a OAuth2 access token by reusing an established access token
• Optimize by increasing the OAuth2 access token timeout 

Are we able to foresee every possible performance issue that will surface after go-Live? Very hard.

Why? APIs are exposed to consumers in the public. There are no fixed usage pattern. We can usually optimize based on past experience, but usually tweaking is required after go-Live for each deployment.

.