APIs (Application Programming Interfaces) have changed the way data transfers between applications and services. It has been at the heart of the digital transformation we have seen over the past decade or so. Working effectively and efficiently with APIs as a developer is fundamental to being able to successfully deliver digital transformation projects in the modern world. Without APIs, the digital transformation we have seen over the last few years would not be possible.
Why Mock APIs on Azure?
The challenge when working with APIs as a developer can be that sometimes you don’t want to, or can’t, connect to a live API during development, whether because the API isn’t ready, or the API connects to sensitive or live data. These limitations can inhibit the scope of your development and testing to a degree that makes it very difficult to produce high quality applications.
This is where API mocking comes in. API mocking is where a dummy version of an API is spun up that produces a pre-defined and static output that lines up with what the intended API will produce. This allows the developer to develop and test against a production-like equivalent of any API without needing to call the live version of it.
How to Mock APIs on Azure
Azure is a great platform for mocking APIs; it supports several services that enable API mocking to various requirements and needs. Through API Management (APIM), you can quickly and easily setup mock APIs that return responses in accordance with any given API specification. You can create serverless mocks using Azure Functions to return responses exactly as you’d like them, all of which can integrate neatly with Azure DevOps to align with your CI/CD (Continuous Integration/Continuous Deployment) goals.
Practical Examples: Mocking with APIM
So, what are some practical examples?
Perhaps the most commonly used method of mocking APIs in Azure is with Azure APIM. APIM is an incredibly powerful API hosting service that is perfect for mocking APIs. All you need to do is import an API specification, and through the built-in ‘mock response’ policy, it will return responses exactly as outlined in the API specification. It’s that simple. Beyond that, you can do some more complicated logic, such as routing conditionally to a mocked or real operation within an API, or to entirely different APIs altogether.
Policies within APIM are very customisable and allow for complex logic beyond simple API operations. One specific use case for this could be when working with an API that isn’t live or ready yet, but the API specification is defined. I have worked on one project where this was the case. A downstream API was being developed at the same time as the integration, but only the API specification was ready, so we set up a mocked API to enable us to begin development before the downstream API was ready. This allows developers to code against the mock and have something to test against, and then when the actual API is live, the mock can be decommissioned with minimal friction.
Below is a video that guides you through how to make a mock API in APIM using an Open API specification:
Practical Examples: Mocking with Azure Functions
Another practical example of mocking is with Azure Functions. As a serverless code hosting platform, Azure Functions allows for full Object-Oriented Programming (OOP) language code projects to be deployed and running within Azure. This means a developer could write a function to return mocked responses given any code logic to mimic eventual production functionality. This can be done by passing in any given parameter that can resolve into logic to return any desired response. For example, you could pass in a response code parameter, and the function then returns a mocked response with that response code, which can help satisfy different tests.
One example in which I have done something like this is using the ‘NSubstitute’ package, specifically for unit tests. This allows you to create unit tests where external systems can return mocked data, which allows you to test your code in its entirety. Similarly to APIM, this can enable HTTP requests to a function that will eventually reach live downstream endpoints, without needing to call live endpoints. This allows for earlier and more robust testing. One specific use case for this could be mocking an external request within a function, so that the entirety of a function can be unit tested without needing external access.
Tips for Mocking APIs on Azure
What are some best practices when working with mocking, particularly within Azure?
- As with anything in Azure, using proper resource tags and naming conventions is essential, as it can clearly inform any user of an API’s mocked nature. Confusing real world and mocked responses is a recipe for disaster and should be avoided where possible.
- Documenting mocked behaviour clearly in wikis or repos is another way of avoiding this confusion, while also guiding a user on how the mocked API is intended to be used.
- Avoiding business logic is important to keep the lines between what is being tested and what is being faked clear. The goal is not to replicate the full behaviour of the endpoint, just the output.
- Finally, mock lifecycle is worth considering. The goal of a mocked API is always to remove it at some point, defining a clear stage where the mocked API should be decommissioned could be helpful, such as before going to Test.
Conclusion
Mocked APIs are borderline essential when delivering digital transformations. Particularly for cloud platforms like Azure where the strengths come from scalability, mocking APIs allows developers to develop earlier, have more robust testing and ultimately reduce cost for the project. This results in a more reliable platform all while reducing development complexity and making any project easier to manage. It is a must-have tool in the belt of any developer working with APIs.
