There are three typical approaches to load testing an API. These, as well as various hybrids, each have drawbacks and advantages.
#1 Faking it – API Mocking
The least useful for load testing is API Mocking These are basically temporary placeholders used during development of an API. Developers use these for early unit testing. But they also provide these “dummy” versions to other teams that need to call the unfinished API from within their own code.
Mocks return hard-coded responses, the formats of which often change during development. Also, the effort to create the mocks is wasted after their initial use.
Remember that, mocks aren’t yet hooked up to actual data sources, their performance isn’t at all representative of the real world. In summary, mocks may be useful for unit testing, but they aren’t representative of the real world.
#2 Cloning it – A Full Test Environment
This approach stands up a full-blown test environment using a snapshot of production data. 
Often you’ll have a copy of all the applications running, too, because your code relies on other APIs, not just database queries.
Often you’ll have a copy of all the applications running, too, because your code relies on other APIs, not just database queries.
The good in this approach is that it’s very representative of the live system’s performance. If your load test brings the system to its knees, no problem! It hurts no one.
However, they raise privacy concerns, require constant data reloading, and can be very expensive if calling third party APIs.
#3 Hitting production – Load Testing Live APIs
Sadly, the method so many companies use is to test on production itself. Why? Well, it’s live, so it’s the most representative of all methods. It’s also “easy” – no separate test environment to stand up and maintain.
Disadvantage is that all data created are actual and stateful. And you still have to worry about the cost of pay-per-use APIs.
It’s important to schedule your load test “off hours.” And, any break would cause your production to become down.
#4 API Virtualization – The Risk-free Approach
You want to perform an exhaustive load test of your API – and keep your existing customers and your job. That rules out hitting the production system. And, you also need more than a test version of your API in a cloned environment. You need to test the real API in an environment where you can control the load condition for aspect of the test.
That’s where API Virtualization comes in. A virtual API provides a sandbox environment where you can simulate environmental loads on network bandwidth, server and database connections, simultaneous users and more.
With API virtualization, minimal resources are required for standing up and testing the API. You test the API itself, not the end-to-end application with all its required backend systems. This eliminates the need for a clone of the production environment.
You can test your API in isolation, gauging the reaction against real data, under a variety of load conditions.
API Virtualization allows you to load test your API in isolation from the rest of the system. With complete control of the test conditions, you can simulate network load, maximum connection limits, latencies and other conditions that happen in the real world.
