Risks of using services and APIs
- [Presenter] One of the main goals of testing is to reduce risk, and API testing is no different. But what kind of risks might an API present? Well, in this video, I'm going to go over a few areas of risk that you might want to consider in API testing. Things like API changes, availability, timing, performance, and security. So what kind of things might change in an API and how might that introduce risk? Well, if you're using a public API, the maintainers usually try not to change the way that it works, but version changes can introduce a lot of risk if you need to move over to using a new version of an API. And then if you're testing a private API, it might be more flexible in when and how things change and not be as strict about versioning the interface itself so the endpoint names or the data that they require could change. This can be quite frustrating if you have to keep changing your tests. And as with any code, changes also introduce the risk of bugs. But just because the interface doesn't change doesn't mean there are no risks. So even if your interface isn't changing, there might still be risks there from things happening on the server that can introduce risks. Availability risks have to do with making sure that the API is available when it should be and is not available when it should not be. So one thing that can affect this is network issues. In this course, we're learning about testing web-based APIs. And that means that we generally need to send and receive these requests through the internet. And you're testing, you should be trying to figure out what might happen if there's network flakiness. Another thing that can affect availability is the permission settings on an API. Permissions are used to stop unauthorized people from accessing different parts of the API. But in testing this risk, you should be looking at both sides of that coin, right? Are we only allowing the correct people to see what they're allowed to and are we also stopping people from seeing things that they're not allowed to see? The timing of API calls can also be an important testing consideration. It's easy to think of API testing as making sure that each endpoint does what it should, but APIs are used as part of a broader ecosystem and this can cause some interesting failure points. For example, I've seen situations where calls could get processed in a different order than they were sent, maybe due to a network glitch or another race condition. A call that was sent second was received first. And this is an important risk to think about as it can sometimes cause some very strange behaviors. Another timing risk is around slow calls. Can a call time out? If it does, how does the server deal with it? If not, does it cause any issues for other calls? It can be difficult to create test conditions for slow calls, but this is an important risk to think about in API testing. Another important risk is concurrency. Most modern applications can handle multiple users at the same time and do a pretty good job of managing conflicts, but it's still worth investigating how your API handles it when two users want to manipulate the same resource at the same time. Performance is also an important risk to think about. Generally, when a person is using a website UI, they can only interact with it as fast as they can click, tap, or scroll. But APIs are designed for programmatic access. That means they're often meant to be interacted with through code, and code can be set up to call a lot of things very quickly. So it's important to think about API performance. Rate limiting is a way that you can limit the number of calls that one user or script can make in a given time period. So if the API that you're testing has rate limiting, you'll want to consider how that might affect things. And if it doesn't have rate limiting, you might want to look at what could happen if a malicious user or even just some buggy code were to suddenly send a big spike of requests. Since it's fairly easy to program scripts that interact with APIs, they form a very common attack vector when people are trying to attack a site. This course isn't about performance or security testing, but even if you aren't an expert in these things, it's still helpful to think about them and to be aware of some of the risks that come with them. Testing is about mitigating risks. So let's continue on with some practical examples of how to approach mitigating the risks that we've talked about in this video.