API Testing Cheat Sheet

These days, every tester knows what an API is and how to test it. At least, that’s what they say when you ask.

I started testing APIs back in ~2010, and the first time I publicly spoke about it was at the second Bugs'a'loud QA Meetup in 2014. How do I remember? I checked the BugsAloud website. Looking back now, that talk was average at best, but the topic is still just as relevant today.

Even now, I often see API testing done at a very surface level, especially when it comes to public APIs. Yes, logic and functionality are the main priorities - like any software, an API exists to solve a specific client problem.

But API testing shouldn’t stop at the obvious checks. Below, I’m sharing a quick API testing cheat sheet. While these might not be the most critical issues, they are important and can quickly expose deeper problems. Since most modern web and mobile apps rely on REST APIs, this checklist is focused on REST-style APIs.

? Security & Headers

• If the response headers contain a server version, that’s a bug - this information should never be exposed.
• Sending a request with the OPTIONS method should return 204 No Content, along with a header listing supported methods.
• Sending a request with an unsupported HTTP method should return 405 Method Not Allowed.

? Data Handling & Input Validation

• Trimming: Send data with extra spaces at the beginning and end. Expected result? The spaces should be trimmed. I’ve seen too many cases where untrimmed strings led to data corruption or broken third-party integrations.
• Limits: Input validation should always happen both on the client and server sides. Check not only individual field limits but also object limits (if multiple objects can be created in a single request) and request size limits.

? Authentication & Authorization

• Try accessing an endpoint without authentication or with invalid credentials. Expected result? 401 Unauthorized (not 403 Forbidden!).
• If you’re using token-based authentication, try invalidating the token and accessing the endpoint again.

? Response Codes & Handling

• If a GET method allows querying specific data but returns nothing, 404 Not Found is incorrect - it should be 200 OK with an empty object. 404 means the resource doesn’t exist, not that there’s no data.
• If an object ID is in the URL and you try accessing another user’s data, returning 403 Forbidden is incorrect - this confirms that the resource exists. The correct response? 404 Not Found.
• If a GET endpoint returns a list of data but has no pagination or limit, that’s a bug - eventually, performance will degrade.
• If an API uses POST for data retrieval, it’s probably a bug. POST should only be used for data retrieval in very specific cases, like complex reporting systems where filters are too large for URL parameters.

? Performance & Abuse Prevention

• Rate limiting applies not only to public APIs. Web and mobile APIs are easy to abuse, so test whether there’s a reasonable request limit. The expected response for excessive requests? 429 Too Many Requests.
• If an API is not public, check that cross-origin requests from another domain are blocked (expect CORS errors in the console).

This is just a starting point, but I wanted to highlight how even a small API testing scope can quickly expand when you consider all the critical aspects beyond just functionality.

#API #SoftwareTesting #QA #TestingCheatSheet #RESTAPI #lengvasbudasismoktitestuoti #qaontime #testspread