As we have dwelled upon in a number of previous posts here at SmartBear, creating monitors for APIs you either provide or consume (or both) should be a cornerstone in your online quality strategy. Now that API Monitoring has a free version you hardly have any excuses left – right? Actually, one of those last excuses stopping you from setting up your first (free) API monitor might be that you don’t really know what to consider and where to start when setting it up – so let’s remedy that in a pinch and get you going with some hands-on tips for creating your first API monitor.
1. Re-use functional Tests from development
If you’re providing your own APIs then re-using functional API tests created during development and testing for monitoring has several advantages:
- Instead of just checking availability, “real” functionality of your API will be scrutinized continuously, providing you with a safety net for continuous deployment practices and infrastructure changes
- Given that your functional API tests are set up to assert and provide relevant error messages, the corresponding API monitors will have the ability to give you much more detailed error information for root cause analysis than regular availability monitors.
- Given that your functional API monitors mimic expected usage scenarios, their actual structure can tell Ops how your APIs are expected to be used, and help them set up the API infrastructure accordingly.
- Obviously, using one tool for creating tests and monitors is lower overhead in maintenance, learning, cost, etc.
2. Create tests that mimic your use cases
If you are mainly integrating with 3rd party APIs (for example Twitter, Google Maps, etc) you need to make sure that you know about their failures before your users notice Here it is essential that the monitors you create actually mimic how you use that API; for example, if you are using the Flickr API to get the latest photos for a certain group on Flickr, make sure your API monitor does the same thing, and not get a list of popular cameras (or anything else that is easier to set up). Also, make sure you monitor the entire flow of your use cases; don’t just monitor the first API request; monitor them all, in sequence – just like your application uses them.
3. Be prepared for changing data
This is a tricky one when it comes to monitoring 3rd party APIs. Often your monitor will want to validate some kind of output based on your input; for example you might validate the coordinates or route-plan you get back from one of the Google Maps APIs to give you the expected results every time. Unfortunately though, Google updates coordinates on the 4th decimal rather frequently, so if your monitor doesn’t take that “volatility” into account – it might fail unnecessarily. The same goes for route-planning; perhaps a traffic jam is making Google return a different “unexpected” result for a limited period of time – something that you need to be prepared for (and that you could actually use to your advantage – I’ll save that for another blog-post).
On the other hand; if you’re not going to validate the returned data in an API monitor, what are you going to validate to make sure it’s working as required? This is a tough call to make, I recommend you at least be defensive with data-validations; don’t do too many and try to focus on those you think won’t ever change.
4. Use a dedicated account
Many (most) APIs require you to specify some kind of credentials or access key in your requests; make sure you are using a dedicated account(s) for your monitoring, both for your own APIs and third-party ones. There are several reasons for this, including:
- For your own APIs, it makes you run your monitors with the same access rights as your users, so you can detect problems that might not affect “super-user” accounts
- For third-party APIs, it allows you to plan billing and utilize bandwidth separately from your “production” API usage
5. Don’t overdo it
As much as we want you to use our products (free and commercial), I urge you to not overdo your API monitoring. You probably don’t need to monitor from every location in the world, or exercise all operations in all your APIs with every possible input. Instead, make sure your API monitors are a safety net for catching problems within the “hot-spots” of your API and make sure to cover those areas that are most vital to your API business. Overdoing things will just result in poorly maintained API monitors, which start to fail, which you will start to ignore, which in the end won’t provide any value to anyone (not even us).