Don't Let Third-Party APIs Fly Under the Radar
In the first part of this series I gave an overview of how APIs come into play when building mobile solutions and outlined the necessity of testing APIs from functionality, performance and security points of view. But if your APIs are dependent on third-party APIs to provide their functionality, you have several more challenges ahead of you. For one thing, can you be sure that these third-party APIs will always return the same results for a given input?
For example – map coordinates change frequently at Google – as do route calculation results and standard search results (not surprisingly). If the responses returned by your APIs are dependent on these APIs – how do you reliably validate that your APIs are working as they should?
One way to handle this could be to set up simulations of your external APIs. These simulations would be configured to return a predefined set of responses - which in turn gives a fixed environment to run under and shields your tests from unexpected changes in external data. Also, it facilitates load testing of your APIs, as they wouldn’t load the external APIs, which would affect the integrity of your load test.
Another way is to make sure the assertions in your tests are immune to changes in external data – which is unfortunately harder than it might sound because almost all external data can change - even data that you thought immutable, like geographic coordinates.
Monitor all your APIs
So you’ve unit-tested and reviewed your code, created functional tests for your APIs, run load tests and security tests, even created simulations of some “unreliable” third-party services to give you a reasonably stable testing environment. Off to production they go!
But your quest for quality doesn’t stop here (right?) – once your APIs are in deployment you need to make sure that they continue to work as required, and you definitely need to be the first to know if they don’t. Monitoring your APIs is crucial at this point; not just basic availability monitoring, but functional and performance monitoring that make sure your APIs behave just as nicely in production as they did during development and testing. If you’re into DevOps and doing continuous or automated deployment, comprehensive monitoring becomes even more important as it serves as a safety net that ensuring your APIs continue working for each release cycle.
Since you’ve already created a large set of API tests during development and testing – you can now seriously benefit from re-using them as production monitors (for both functionality and performance) which has several benefits:
- You are monitoring actual functionality and user transactions – not just availability
- Reuse of tools and know-how within the organization
- Failing monitors (i.e. tests) will give detailed error information back to the development team for root cause analysis
And, as a bonus, the tests themselves will indicate to operations how your APIs are expected to be consumed (as they should simulate real client behavior) – allowing operations to provision and architect their infrastructure accordingly.
Once again the complexity of using third-party API quality rears its head: should you monitor them as well? Definitely! Just as you want to be the first to know when your own APIs fail, you want to know when APIs you depend on fail so you can take the necessary precautions. Therefore you should create similar functional monitors for third-party APIs as you do for your own APIs and schedule them accordingly (see more on this in Lorinda Brandon’s blog-post “The Viral Bump: Will your App Survive?”).
Next week we'll dive into how SmartBears excellent toolset for API testing and quality can help you tackle many of the described obstacles - putting you up for unrivalled success with you APIs. See you then!