DEV Community: Liudas

API! API! API! 👏

Liudas — Mon, 19 Oct 2026 07:35:50 +0000

If you’ve been working in software long enough, you probably understand Steve Ballmer’s enthusiasm. 😄

APIs are everywhere.

Mobile applications communicate with backend services through APIs. Websites retrieve and modify data through APIs. Enterprise systems exchange information through APIs. Cloud platforms expose almost everything through APIs, and even physical devices increasingly provide APIs for integration and automation.

The graphical interface may be what the user sees, but in many systems, the real work happens underneath it.

I started testing APIs around 2008. Almost two decades later, the technologies have changed enormously, but many of the problems haven’t.

Unexpected inputs. Incorrect access decisions. Broken HTTP semantics. Server errors. And, of course, the legendary 200 OK when absolutely nothing is OK.

In 2017, Dylan Beattie even turned these frustrations into a brilliant parody of Bon Jovi’s You Give Love a Bad Name, called You Give REST a Bad Name.

Some API problems are apparently timeless. 😄

And that’s exactly why we build https://rentgen.io

API! API! API! 👏

API Regression Testing: Turn Every Production Bug Into a Reusable API Test

Liudas — Thu, 08 Oct 2026 08:32:47 +0000

A production API defect should surprise you only once.

Every production bug reveals an assumption that was not tested. After fixing it, reproduce the original request, verify the correction, and turn the scenario into a reusable API regression test.

This is especially important for:

API authorization failures
Input validation bugs
HTTP protocol errors
API performance issues
Pagination problems
Security vulnerabilities
Data integrity failures
Third-party integration defects A code fix solves the problem today. A reusable API test helps prevent the same defect from returning in a future release.

The goal of API testing is not only to find and fix bugs. It is also to preserve what the team learned and continuously expand the system’s regression coverage.

This is the tenth rule in The Power of Ten Rules for Testing HTTP APIs.

Read the complete article: https://qaontime.com/research/the-power-of-ten-rules-for-testing-http-apis.html

Your API Can Create the Customer—and Still Be Broken

Liudas — Tue, 06 Oct 2026 10:03:53 +0000

A successful POST /customers response does not prove that your API is correct.

It only proves that one business operation worked under one specific set of conditions.

Modern APIs are not just business functions. They are also implementations of a communication protocol. Clients depend on more than the response body:

HTTP methods
status codes
request and response headers
content types
authentication behavior
caching directives
content negotiation
idempotency
consistent error handling When these rules are violated, the API may appear healthy during a happy-path test while still breaking clients, integrations, SDKs, proxies, gateways, or production workflows.

A simple example

Imagine a customer API that correctly supports:
POST /customers GET /customers/{id} PUT /customers/{id} DELETE /customers/{id}

The main business scenarios work. Customers can be created, retrieved, updated, and deleted.

But what happens when you test the protocol around those operations?

Does PATCH return an appropriate response if it is unsupported?
Does OPTIONS describe the endpoint correctly?
Does HEAD behave consistently with GET?
Is an invalid Content-Type rejected?
Is an unsupported Accept header handled correctly?
Are authentication failures represented consistently?
Are cache directives present where they should be?
Does repeating an idempotent request produce a predictable result?
Do all endpoints return errors in a consistent format?

These are not cosmetic details. They are part of the API contract.

Business logic is only half the API

A common testing pattern is:

Send a valid request.
Check for 200 or 201.
Verify a few fields in the response.
Move on.

That test may be useful, but it covers only one path through the system.

An API consumer also relies on predictable protocol behavior. For example, a client may use:

Content-Type to describe the request body;
Accept to negotiate the response format;
status codes to decide whether to retry;
headers to control caching;
authentication responses to refresh credentials;
idempotency guarantees to safely repeat operations.

If those behaviors are inconsistent, the business operation can still succeed while the integration remains unreliable.

The infrastructure excuse

One of the most common assumptions is:

“The framework, API gateway, or infrastructure handles that.”

Sometimes it does. Sometimes it does not. Even when a framework provides defaults, the final behavior may be changed by:

custom middleware;
reverse proxies;
gateway configuration;
authentication layers;
endpoint-specific code;
error handlers;
caching policies;
deployment differences.

The API consumer does not care which layer caused the behavior. They experience the final HTTP response.

That is why protocol behavior needs to be tested at the API boundary.

What protocol-level API testing should cover

At minimum, test both valid and invalid protocol usage:

HTTP methods
Verify supported methods and confirm that unsupported methods return appropriate responses.

OPTIONS and HEAD
These methods are often ignored, incorrectly configured, or inconsistent across endpoints.

Content-Type
Check whether the API rejects unsupported, missing, or misleading content types.

Accept and content negotiation
Test how the API behaves when clients request supported, unsupported, or malformed response formats.

Authentication behavior
Do not test only successful authentication. Also verify expired credentials, missing credentials, invalid tokens, insufficient permissions, and consistent error responses.

Response headers
Headers can affect caching, security, client behavior, observability, and interoperability.

Caching directives
Check whether Cache-Control, ETag, Last-Modified, and related behavior match the endpoint’s requirements.

Idempotency
If an operation is expected to be idempotent, repeat it and verify that the outcome remains predictable.

Error consistency
Equivalent protocol failures should not produce completely different response formats depending on which endpoint was called.

Why this matters

Protocol defects often survive ordinary functional testing because the happy path does not expose them.

They may only appear when:

a mobile client sends a different header;
an SDK retries a request;
a proxy caches a response;
a browser sends an OPTIONS request;
a client negotiates a different representation;
a token expires mid-flow;
an integration uses an unsupported method;
a request is repeated after a timeout.

At that point, the API may be “functionally correct” according to its internal business logic, but incorrect from the consumer’s perspective.

That is still a defect.

A practical rule

When testing an endpoint, do not ask only:

“Did the operation work?”

Also ask:

“Did the API behave correctly as an HTTP protocol implementation?”

This changes the test mindset from checking isolated outcomes to examining the full contract around every request.

Where Rentgen fits

Rentgen is designed to explore this space before teams invest time in large automation suites.

Starting from a single request, it can generate structured checks around:

invalid input;
boundary values;
missing fields;
malformed payloads;
header variations;
authentication behavior;
method handling;
protocol-level edge cases.

The goal is not to replace contract tests, integration tests, or CI regression suites. The goal is to expose assumptions early—before they become permanent gaps in the test strategy.

Final thought

An API is not correct merely because it can create a customer.

It is correct when it behaves predictably across the protocol that consumers depend on.

Test the business logic—but test the protocol around it too.

Read the complete white paper: https://qaontime.com/research/the-power-of-ten-rules-for-testing-http-apis.html

API Abuse Prevention: API Testing Rule 8/10

Liudas — Mon, 05 Oct 2026 04:14:55 +0000

A valid API request can still take down a service.

API abuse is not always malicious. Retry storms, broken integrations, excessive polling, misconfigured automation, and large data requests can generate enough traffic to exhaust shared resources. Each request may be valid on its own, but the combined effect can increase latency, consume database connections, and reduce availability for every other consumer.

Every API should defend itself against excessive resource consumption. API testing should cover rate limits, quotas, expensive operations, concurrent requests, large-volume retrieval, retry behavior, resource exhaustion, and fair allocation between consumers.

For example, an expensive search or report endpoint may work correctly under normal traffic but become a serious reliability problem when a client repeatedly calls it hundreds of times per second. The same applies to endpoints that return large collections or allow aggressive polling without meaningful restrictions.

Protection may be implemented in the application, API gateway, infrastructure, or a combination of these layers. What matters is the observable result: one consumer must not be able to significantly degrade availability for everyone else.

Testing should verify not only that limits exist, but also that the API responds predictably when those limits are exceeded. Clients should receive clear failure responses, while the service remains stable and available.

An API that assumes all consumers will behave correctly is an API that has not been fully tested.

This is Rule 8 of The Power of Ten Rules for Testing HTTP APIs. Read the complete research article for the full explanation and testing guidance: https://qaontime.com/research/the-power-of-ten-rules-for-testing-http-apis.html

Rentgen is an API discovery tool built to reveal behavior beyond normal usage assumptions and expose reliability risks before they become production incidents.

Automation Before Automation.

Idempotency and Concurrency in APIs: API Testing Rule 7/10

Liudas — Fri, 02 Oct 2026 09:45:25 +0000

A payment request that works once may still charge the customer twice.

State-changing API operations must be tested beyond the first successful request. Creates, updates, transfers, and deletes can behave incorrectly when clients retry after a timeout, replay a completed request, or send identical operations concurrently.

API testing should verify repeated requests after success, retries after lost responses, concurrent requests using the same idempotency key, different updates against the same resource, and updates based on stale data. The expected behavior may be deduplication, conflict detection, serialization, or returning the original result, depending on the API contract.

For payment APIs, reusing the same idempotency key and request must not create a second transaction. The same protection should work when identical requests reach different service instances at the same time. Similarly, concurrent updates must not silently overwrite valid changes made by another client.

Do not verify only the HTTP response. Inspect the final resource state, transactions, emitted events, audit records, external side effects, and asynchronous jobs. Two successful responses must not create duplicate payments, repeated orders, lost updates, or partially completed operations.

Testing idempotency, retry safety, replay protection, and concurrency is essential for reliable APIs and distributed systems. Rentgen is an API discovery tool built to test what an endpoint actually does beyond one successful request.

Read the complete API testing white paper: https://qaontime.com/research/the-power-of-ten-rules-for-testing-http-apis.html

Automation Before Automation.

API Testing Rule 6/10: APIs Must Fail Predictably

Liudas — Wed, 30 Sep 2026 12:40:07 +0000

API failures are inevitable, but they should never be unpredictable. Invalid requests, missing resources, authentication failures, rate limits, dependency outages, and internal errors are different conditions. They should return different and meaningful HTTP status codes instead of collapsing into a generic 500 Internal Server Error.

Predictable API error handling allows clients to understand what happened and decide whether to fix the request, authenticate, retry later, or stop. Similar failures should produce consistent status codes, stable error structures, and useful messages without exposing sensitive implementation details.

For example, a missing resource should return 404 Not Found, a malformed request should return 400 Bad Request, and a rate-limited client should receive 429 Too Many Requests. A 500 Internal Server Error should indicate that the server failed while processing an otherwise valid request—not that the client submitted invalid data.

API testing should cover validation errors, missing resources, authentication and authorization failures, unsupported operations, rate-limit violations, timeouts, dependency failures, and unexpected internal errors. Testers should verify that error responses are consistent, actionable, secure, and easy for API clients to interpret.

Any reproducible request that consistently generates a 5xx response should be investigated as a potential defect. Reliable APIs are not defined only by successful responses. Predictable failure handling is a core part of API reliability, REST API design, and software quality.

Rentgen is an API discovery tool built to explore failure paths beyond the expected request and expose assumptions before they become production incidents.

Read the complete API testing white paper: https://qaontime.com/research/the-power-of-ten-rules-for-testing-http-apis.html

Automation Before Automation.

API Testing Rule 5/10: Every Collection Endpoint Must Have Bounded Results

Liudas — Tue, 29 Sep 2026 10:16:12 +0000

GET /customers may work perfectly with 100 records. But what happens when the dataset grows to one million?

Pagination alone is not enough. Collection endpoints should enforce a maximum page size and predictable defaults. API testing should verify what happens when pagination parameters are omitted, extremely large limits are requested, complex filtering and sorting are combined with pagination, or large collections are retrieved repeatedly.

Without server-enforced limits, a single valid request can consume excessive database, memory, network, and client resources. An endpoint that returns unbounded results is a scalability and reliability defect waiting to become a production incident.

In the complete white paper, we explain how to test pagination, maximum page sizes, cursor-based navigation, filtering, sorting, performance under large datasets, and protection against excessive requests.

Read the complete white paper: https://qaontime.com/research/the-power-of-ten-rules-for-testing-http-apis.html

Automation Before Automation.

API Testing Rule 4/10: Authentication Authorization

Liudas — Mon, 28 Sep 2026 06:53:05 +0000

A valid token proves identity, not permission.

Testing whether a user can access their own profile is not enough. Repeat the same request with another user’s resource ID and verify that access is denied.

Check different roles, owned and unowned resources, cross-tenant access, read/update/delete operations, and predictable IDs.

Authentication can work perfectly while authorization fails completely.

Rentgen helps discover these issues by testing API behavior beyond the expected authenticated request.

Read the complete white paper:https://qaontime.com/research/the-power-of-ten-rules-for-testing-http-apis.html

Automation Before Automation.

I Made a Physical Notebook for Software Testers. Yes, in 2026.

Liudas — Fri, 18 Sep 2026 17:51:40 +0000

We have Jira. Notion. Confluence. Test management systems. AI assistants. Automated test suites running in CI/CD. So naturally, I made a paper notebook.

Not because I suddenly became nostalgic for the 1990s, and definitely not because I think QA teams should start documenting test cases with a pen. The reason is much simpler: after many years in software testing, I still find that some of my best testing happens before I open another tool.

When I start testing something new, I usually need to understand the problem first. What changed? What can go wrong? What assumptions are we making? What don't I understand yet? What did I just observe that looks strange?

And somewhere between Slack, Jira, browser tabs, API clients, DevTools, and documentation, those thoughts disappear surprisingly quickly. So I created the QA Notebook.

This is not a test case repository. That was probably the most important rule when I started designing it. I didn't want another place where a tester writes:

Step 1: Click Login
Step 2: Enter username
Step 3: Enter password
Expected result: User is logged in

We already have enough tools for storing things like that. I wanted something for the part of testing that happens before everything becomes structured and repeatable. Each testing session starts with a few simple questions: What am I testing? What changed? What can go wrong? What are the known risks? What did I learn? What is still uncertain? And finally: Do I have enough confidence to move forward?

Yes. No. Or with known risks.

The page next to it is intentionally mostly empty. Because testing doesn't always fit into predefined fields. Sometimes you need to draw a flow. Sometimes you write down three API responses. Sometimes you discover a weird state transition and draw arrows everywhere. Sometimes you have a hypothesis that turns out to be completely wrong ten minutes later. That's fine. The notebook should help the investigation, not force the investigation to fit the notebook. Good testing starts with questions, not test cases

One thing I've tried to put throughout the notebook is small reminders that interrupt the usual testing routine.

For example: A 200 OK response can be a bug.
Test what developers didn't think about.
Every assumption is a potential test case.
If the UI prevents something, check whether the backend prevents it too. A passing test only tells you what happened under one set of conditions.

These aren't supposed to be profound quotes hanging on an office wall. They're there because sometimes one question is enough to send your testing in a completely different direction.

You might be testing a perfectly normal form, see a reminder about boundaries and suddenly try the value just above the documented maximum.

You might be testing permissions and notice: A disabled button is not an authorization control. So instead of stopping at the UI, you inspect the API. That is exactly what I wanted this notebook to do: occasionally give the tester one more idea. Bugs need investigation, not just tickets. I also added dedicated bug investigation pages.

When something strange happens, my first instinct isn't necessarily to immediately create a Jira ticket. First I want to understand what I actually found.

What happened? What did I expect? Can I reproduce it? What changed? What evidence do I have? What am I assuming? What is the smallest reproducible case? That last question is particularly useful.

A giant broken workflow involving twelve steps, three users and two services isn't very helpful if you can reduce the same problem to one request. So the investigation pages have space to work through that before turning the finding into a polished bug report.

I also wanted the notebook to generate testing ideas. There are reference sections scattered through it rather than putting 150 pages of blank templates together and calling it a QA notebook.

There's SFDIPOT for when you think you've run out of things to test: Structure, Function, Data, Interfaces, Platform, Operations and Time.

There are reminders to look beyond functional behavior into performance, security, reliability, usability, accessibility, compatibility, scalability, recoverability, availability, localization and observability.

There are sections specifically about API testing: authentication, authorization, input validation, headers, CORS, status codes, rate limits, oversized requests and other things that are very easy to forget when the happy path works perfectly.

Toward the end I added practical reminders about decision table testing and state transition testing, because interesting bugs often don't live in a single condition or state. They live in combinations and transitions.

The notebook ended up being 162 pages, but the goal was never to create a QA textbook. It's something that should sit next to the laptop while you're actually testing.

Why paper? This is probably the strange part.

I work in IT. I build automation. I use AI. I write Playwright tests. I work with APIs and CI/CD. And I still like writing things down.

There is something different about having a notebook open next to the keyboard while investigating a system. I don't have to decide where the note belongs. I don't need to create a ticket. I don't need to format anything. I don't need another browser tab. I can just write: "Why did this return 200?" Circle it. Test something else. Come back to it twenty minutes later. Maybe it becomes a bug. Maybe it becomes a test. Maybe it becomes nothing because my assumption was wrong. That's testing.

The notebook doesn't need to preserve every thought forever. It needs to help me think while the investigation is happening. Automation Before Automation. There's a line in the notebook that probably summarizes the whole idea better than anything else: Think first. Test second. Automate when it makes sense. I'm obviously not against automation. Quite the opposite.

But automation becomes much more useful after we understand what behavior matters, what risks we're protecting against and what conditions are worth checking repeatedly.

Before asking "How do we automate this?", somebody still has to ask: "What should we test?" That's the space I wanted the QA Notebook to live in. Not instead of Jira. Not instead of Playwright. Not instead of AI. Just next to the keyboard. With a pen. And preferably a tester who keeps asking one more question.

QA Notebook — Think. Test. Question. Write it down.

by Liudas Jankauskas
https://www.amazon.com/QA-Notebook-Liudas-Jankauskas/dp/B0HH6MNG4Z

API Testing Rule #3: Response Codes Are Part of the Functionality

Liudas — Thu, 17 Sep 2026 05:12:27 +0000

An API does not communicate only through its response body. The HTTP status code is also part of its contract.

A successful request should not return the same status code as an authentication failure, invalid input, a missing resource, or an unsupported HTTP method. Clients, monitoring tools, and other services rely on these distinctions.

For example:

201 Created for a successfully created resource
400 Bad Request for invalid input
401 Unauthorized for missing or invalid authentication
403 Forbidden for insufficient permissions
404 Not Found for an unavailable resource
405 Method Not Allowed for an unsupported method
429 Too Many Requests when rate limits are exceeded
500 Internal Server Error only for unexpected server failures
Incorrect response codes can hide bugs, confuse API consumers, and expose information about protected resources.

Response code testing should cover both successful and unsuccessful scenarios. An API that returns the wrong status code is not behaving correctly, even if the response body looks reasonable.

Rentgen helps explore these cases automatically from a working cURL request, including invalid input, authentication failures, unsupported methods, and unexpected responses.

HTTP status codes are not decoration. They are functionality.

Full white paper:
https://qaontime.com/research/the-power-of-ten-rules-for-testing-http-apis.html

API Testing Rule #2: Every Endpoint Must Be Tested With Invalid Input

Liudas — Tue, 15 Sep 2026 11:41:41 +0000

A successful request proves only that the happy path works. It does not tell you how the API behaves when the input is incomplete, malformed, unexpected, or too large.

Most real defects appear when application assumptions are violated. That is why every endpoint should be tested not only with valid data, but also with invalid input.

For a user creation endpoint, a valid request might look like this:
{ "name": "John Smith", "email": "john@example.com", "phone": "+971501234567" }

That request confirms that valid data is accepted. However, it does not answer more important questions:

What happens when a required field is missing?
What happens when email contains an invalid value?
What happens when a string is replaced with a number?
Are null values accepted?
Are empty strings rejected?
Are unexpected properties ignored or stored?
What happens when the payload is extremely large?
Does malformed JSON result in a controlled error?

A common API defect is returning HTTP 500 Internal Server Error when the client sends invalid input. The server should reject malformed data with a clear client error, not fail internally.

Oversized values are another important example. An API may accept a user name containing several megabytes of text and return a successful response. The problem might appear later in a report, mobile application, search index, integration, or analytics pipeline.

This makes invalid input testing more than a validation check. It is also a reliability, security, and operational stability check.

At minimum, every endpoint should be tested with:

Missing required fields
Invalid formats
Incorrect data types
null values
Empty values
Boundary values
Oversized strings
Oversized payloads
Malformed JSON
Unexpected properties

The expected result should normally be a controlled 4xx response with a meaningful validation message.

Invalid input should never cause application crashes, database corruption, service instability, unbounded memory consumption, or unexpected HTTP 500 responses.

With Rentgen, this type of testing does not require a large test suite to be written manually. Start with a working cURL request, describe what the fields represent, and let the tool explore variations around the expected input.

The goal is not only to prove that valid requests work. The goal is to discover what happens when the assumptions behind those requests are wrong.

That is where many serious API defects begin.

This is the second rule from The Power of Ten – Rules for Testing HTTP APIs:
https://qaontime.com/research/the-power-of-ten-rules-for-testing-http-apis.html

API Testing Rule #1: Treat Every Endpoint as an Attack Surface

Liudas — Sun, 06 Sep 2026 08:06:03 +0000

“Internal” describes an endpoint’s current audience. It is not a security boundary.

Internal APIs often become dependencies for mobile apps, other teams, partners, automation scripts, and future services. If a request can reach an endpoint, that endpoint must be tested independently.

At minimum, verify:

Authentication requirements
Authorization and ownership boundaries
Invalid input handling
Supported HTTP methods
Response code correctness
Rate limiting
Sensitive information disclosure

CORS should not be treated as protection for the API. It restricts certain browser requests but does not stop scripts, custom clients, or server-to-server communication.

Rentgen is not another general-purpose API client. It is an API discovery tool that starts with one working cURL request and systematically explores behavior beyond the expected path.

This is the first rule from The Power of Ten – Rules for Testing HTTP APIs: https://qaontime.com/research/the-power-of-ten-rules-for-testing-http-apis.html