API Testing – TMI

APIs are like windows into the soul of systems. API testing is like psychology. Well, not exactly.

We use APIs, the windows that the servers give us, to look inside those systems. Sometimes, they show us more than we ask for, and that can be very helpful. It can also be very dangerous.

Let’s look at an example. This time, I’m going out into space. I’m going to use as an example, the Star Trek APIs, because, of course there is something like that, and because it exists, I must use it.

Where no API has gone before

I’m going to use the Star Trek REST APIs to search for Spock, in the movie “The Voyage Home”. Only, I misspelled it. The URL, with the query parameters is incorrect. Between the “the” and “voyage” it should be a “%20” (Space. The character, not the final frontier), like after the “voyage”.

Let’s look at the result, this the response.

First, the status code is 500 – that’s Internal Server Error, which means I broke something in the server. Which is okay, and makes me happy already.

Now, let’s look at the response body. See the “exception” field? Look at the exception text – it’s a Java exception! So the server just told me that the software is built in Java!!

Is that information something that would be useful for a developer? Probably. I see that as part of development and debugging, it would be useful to see the exception message, why something broke inside.

Is it something that will be useful for a user? Not really.

API Testing in the Neutral Zone

This kind of information may not be that important, (although everything about Star Trek is important), But what kind of information does your system expose, when it brings out internal information through its APIs?

We talk about “testing APIs”. But we’re not really testing APIs. We’re looking into the system through a lense. The question is: What kind of information do we expose through these lenses?

If we have multiple interfaces (get item, get all items, REST and graphQL, etc.), is the same data exposed through all the interfaces? When errors occur, what gets exposed?

That can lead us to better understanding of the system we’re testing. What kind of information gets out there, and what kind of exposure it gets. It may be the right amount.

It can also lead us towards doom.

It may just be a wormhole, though.

To scare off the aliens, check out the “Automating API Testing” workshop for developers, and “API Testing with Postman” workshop for testers. Stay vigilant!