See the other side of my TechEd API Management Competition
- Published on
- Reading time
- Simon Waight
Now that TechEd Melbourne is done and dusted I thought I'd publish the results of my competition and share some of the cool configuration and analytics that Azure API Management provides to API Publishers.
First off, congratulations to Kieran and Lachlan for being the two agents of change who were prepared to get in and get dirty!
As you read through the below you can click the images below to see them at a larger resolution.
Who used the API Proxy?
As API Management requires callers to pre-register and identify themselves using keys it is possible for the proxy to identify who is connecting and making the most calls and what they are doing. I put a limitation on the API calls that can be made (see later in this post) so I can see that the top developer was blocked after he hit the 50 calls per day limit.
What did they call?
We also get some metrics on which API operations are being invoked the most by our trusty band of developers (shown above). The calls to VIEWCATALOG were all down to my demonstration during my session and the two calls to UPDATEPRODUCTDESCRIPTION were Lachlan trying his hand (well done!)
The Azure Management Portal gives me some coarsely-grained statistics so I can see what's going on at a glance as shown below.
If I want more detailed analytics though I need to open the API Management Publisher Portal and show the Analytics for the Proxy (the below graph shows all traffic across all APIs including the API from my session in addition to the competition API). This is really one of the valuable pieces of API Management and one reason businesses could adopt this so they can start to understand what parts of their existing APIs are seeing the most demand.
As this was a demo API I wanted to make sure that I didn't end up with a hefty bill by someone accidentally pounding away on the API so I put a few things in place to protect the proxy and the service it was proxying.
Firstly I dropped in a day-long cache of the responses from the backend API.
Rate Limiting and Quota for Calls
I cloned the existing 'Starter' Product that comes as a sample with API Management and put it in place for my API. The product itself is just a container and I need to then apply a Policy to it which I did using the following setup.
<policies> <inbound> <base /> <!-- 10 calls per hour --> <rate-limit calls="10" renewal-period="60" /> <!-- 50 calls per day --> <quota calls="50" renewal-period="86400" /> </inbound> <outbound> <base /> </outbound> </policies>
This was to make the competition a little more interesting (as Lachlan found out :)).
So there we have it, a bit of an insight into what the metrics are that were being generated by the API Management setup that you may have all seen during my demo at TechEd.
If you have any questions please get in touch.