TLDR; Find the minimum request and header set that works. Use that as your base request. Create some expanded versions with more headers, randomise header inclusion and order, these help detect change.
Monitor and Act on Trends
I learned something about automating APIs very early on in my career.
And that is to reverse engineer the use of the API so that you get the minimum request.
And the way that I learned, that was in a very adversarial type environment because no one gave us any information.
So we were reverse engineering everything, we’re trying everything out. And the reason for getting down to the minimum was because the APIs kept changing.
And if you put too much in your request, then when it changed, you had an awful lot to change.
So by getting it down to the minimum you could absorb the change faster because it was simply either taking something else away or adding probably one or two more things.
And the way that I use this in my automating is to do all the Exploratory analysis and reverse engineering in the proxy tools, or Postman, or Insomnia, or whatever other API tool you’re using.
Get it down to the absolute minimum request, then build that as the base abstraction layer.
Then I create assertions that it Remains the minimum.
So I will send requests which I am expecting to fail when I take information out of that request.
Then I have got my base set.
Then what I do is I start asserting on expansion.
So I will add more headers, I will add other fields, but at this point, they are all equivalence classes are.
They don’t need to be there.
They could be pretty much anything that is valid.
Therefore, I can randomly generate the data that is in there or potentially which headers I put in, I can randomly move them about, change the order.
We all know the order of header shouldn’t make a difference, but it sometimes does.
So I will randomly do those things, and I am expecting all those to pass.
The randomization for the expansion should make no difference.
At which point I have got a core set that I can use.
It’s very easy then when the API changes for me to see, has it got to the point where I need to take something away because one of the tests I am expecting to fail has started to pass, or is it got to the point where I am expecting to Expand it, where some of the expansion tests are passing where the minimum set wasn’t.
And so this was all learned from reverse engineering because I reverse engineer, a lot of APIs in the live environment because I end up automating applications that have private APIs, that are not well documented and this learning, which I learned the hard way years ago, has stood me in good stead.
So there’s a little tip.
This was originally recorded on Racket in 202106
Follow on Notes
I’ve mentioned to people before that sometimes the header order matters, and I’ve been vigorously informed that it doesn’t.
But no-one seems to have told some of the APIs that I have worked with that.
Some architectural decisions do often use header order as a way of protecting the API from external use, so if you are spoofing an app then you might have to replicate the order of the headers that it sends out, regardless of any thoughts of “but it doesn’t matter what order”.
Similarly some buffers, like cache systems, load balancers, firewalls etc. Often demand that headers be exactly what they demand, even if the headers are ‘optional’. So some messages need more headers than you might expect, and they might need to be in the right order or they might need the values the buffer wants.
Most people won’t encounter these type of issues because they’ll be testing public APIs. But when you start “Automating The Un-automatable” then you may well find these tipes to be useful
