openskills.info
Course catalog
Course Preview

API Testing

API testing checks a software interface by sending it requests directly and verifying the responses, status codes, data, and side effects, with no user interface involved. It catches broken behavior, bad error handling, and authorization gaps in the services that applications and other systems call over the network.

itSoftware engineering

Don't Panic: API Testing

API testing means talking to a piece of software the way other software talks to it: through its application programming interface, the programmatic front door, with no screen in the way. A test sends a request, reads the reply, and decides whether the reply keeps the promises the interface made. It is less dramatic than clicking through an app, and considerably more honest, because the API has nowhere to hide a bad answer behind a nice layout.

The alternative is to check everything through the user interface, with a browser test clicking buttons for every rule. That works, slowly, and with more ways to fail for reasons unrelated to the rule. API tests sit one floor down, where the data actually changes hands: faster and more stable than browser tests, while still exercising the real service rather than a model of it.

Three ideas carry most of the weight. First, a reply has layers. The status code is the three-digit verdict, so 201 means created, 401 means "who are you?", 403 means "I know who you are, and no", and anything in the five hundreds means the server fell over on a perfectly good request. Headers and the body come next. Checking that a status is merely "some kind of success" is how a 200 sneaks past where a 201 was promised.

Second, a reply is only a claim. An update that says "done" should be followed by a read that proves it happened. A schema check confirms that the data has the right fields and types; it has no opinion on whether those values are true. Shape and truth are separate questions, and the test has to ask both.

Third, HTTP methods come with manners. A safe method such as GET should change nothing. An idempotent method such as PUT or DELETE lands in the same state however many times it is repeated. POST makes no such promise, so a nervous retry can order two of everything, which is why some APIs accept an idempotency key that lets the server recognize the repeat.

Now the surprise. A GraphQL API may reply with a cheerful 200 while the query partly failed, because HTTP has no status code for "sort of". The bad news sits in an errors field in the body, where a status-only test will never look. Likewise, the top risk on the OWASP API security list is not an exotic exploit. It is asking for someone else's record by changing an ID, and getting it. Catching that takes a test with two users, not one.

There is also a whole supporting cast: mock servers that stand in for other services, contract tests that keep two teams from surprising each other, and generators that invent thousands of inputs from an API description. They are useful, and each proves only what it actually exercises.

For the full picture, read the Intro for how a test is built and what each assertion can catch. The Cheatsheet is the lookup table for status codes, method rules, and tool syntax. The Practice tab shows the commands, and the Exercise has you run a small, working suite in containers on your own machine.

Where this skill leads

Relevant careers

See how this topic contributes to broader role-level skill maps.

Sources