Continuing with API basics, let’s talk about what makes testing APIs, and APIs themselves complex. There are just too many moving parts. The examples are taken with Postman, but the content is tool-agnostic.
An API (Really an HTTP request, otherwise we ges even more complex options) consists of 4 parts.
- An HTTP Method. That’s POST or GET, but there others. Here’s a list directly from Postman options.
Yes, you can even create your own method.
- URL. We call that also an endpoint. It’s where the internet will take the request, but that’s also made out of two parts – the server URL, and the relative URL inside the server. While they look like a package deal, they really can be in completely different places.
For example if I make a POST request to:
The server “api.github.com” is probably a gateway that accepts the request, and then reroutes the request after it interpretes where “/user/repos” actually is.
So even the “where” the app is running is really not simple.
- Header fields. Now these are standard and custom fields. Here’s an example of just the defaults from what Postman sends:
We can pass authentication tokens in the headers. We can ask a response to come in XML, through a header field. Or we can send cookies to the server (that secretly planted them on my laptop), as header fields. And of coures we can invent application-specific ones, that we can either send or withhold from the requests. The options and combinations are really endless.
- The request body, or Payload. That can contain anything – JSON or XML, or binary data. Or any of those, but encoded in different ways.
Of course, each request returns a response, containing a status code, headers of its own and a response body. It can look like what we expected, or completely different. The payload can be in any format, size, and can either fit, not fit, or partially fit the use case we’re trying to test.
Here’s a whole request content:
Just right off the bat, if we don’t even think about what the API does, the combinations are really endless. And that’s just one API. They usually don’t come alone. Workflows mean we call different combinations of APIs. You see that {{repositoryName}} ? That one is obtained from a former request, and I’m sending it in this one.
Now go and test all those cases.
We build complex software, and we want to make sure that it works. A lot of the complexity comes just from the infrastructure we use. In this case, we’re using HTTP protocols, which are complex by nature, then add in complex architecture and logic, and finally a whole lot of servers, libraries and dependencies that we didn’t even write.
And then we sum them up with “testing APIs”, which sounds very simple. But API testing can be really REALLY complex.
Now, if you want to dive even deeper into API testing, check out the “Testing APIs” workshop for developers, and “Testing APIs with Postman” workshop for testers.
0 Comments