Forem: Liudas

ReadyAPI vs Rentgen: One Builds Enterprise Confidence. The Other Checks If the API Falls Apart Before That.

Liudas — Wed, 06 May 2026 18:51:14 +0000

There’s a funny moment in API development that almost nobody talks about.

A developer finishes an endpoint, sends one request, gets a beautiful 200 OK back, and suddenly the room behaves like the API survived Normandy.

Then somebody opens ReadyAPI, starts building proper test suites, adds assertions, environments, CI integration, performance checks, maybe even security testing. Serious enterprise stuff. And to be fair, ReadyAPI absolutely deserves its reputation. SoapUI evolved into one of the biggest API testing platforms for a reason. Banks, telecoms, healthcare systems — this is the territory where structured testing matters and auditors enjoy PowerPoint presentations about “quality gates”.

But there’s a problem hiding before all of that.

What if the endpoint was already fragile before the first test suite even existed?

That’s the gap Rentgen focuses on.

Not enterprise automation. Not giant regression packs. Just the uncomfortable two-minute reality check right after “it works”.

Take one working cURL request and start making it slightly annoying. Remove fields. Break types. Add whitespace. Push boundaries. Send malformed payloads. Suddenly APIs that looked very confident five minutes ago begin returning strange status codes, inconsistent validation, or the occasional glorious 500 error.

And honestly, that’s useful.

Because building beautiful automation around assumptions is still building automation around assumptions.

ReadyAPI helps teams define and enforce correctness over time. Rentgen helps expose weird backend behavior before those definitions even exist. Different stage. Different responsibility. No reason they can’t work together.

Full article:
https://rentgen.io/api-stories/ReadyAPI-and-Rentgen-enterprise-test-suites-and-step-before-them.html

Thunder Client vs Rentgen is one of those comparisons that sounds logical until you actually look at how people use them.

Liudas — Tue, 05 May 2026 16:56:35 +0000

Both deal with API requests, both sit somewhere in the development flow, and both are useful. But putting them in the same box is a bit like comparing a screwdriver with a crash test. Yes, both are involved in building things. No, they are not doing the same job.

Thunder Client lives exactly where developers spend most of their time — inside the editor. You write some code, tweak an endpoint, open Thunder Client, send a request, get a response, fix something, repeat. It is fast, lightweight, and does not force you to jump between tools like a caffeinated squirrel. For day-to-day development, that convenience matters more than people like to admit.

But here is the part everyone quietly skips. You send a request, it returns 200, JSON looks fine, and someone inevitably says “works.” Which is technically correct, in the same way that starting a car proves it can move forward. It does not prove the brakes work when you actually need them.

Manual API clients, including Thunder Client, do exactly what you tell them to do. Nothing more, nothing less. If you test a valid request, you get a valid response. If you think about edge cases, you can test them too. But that thinking still depends on you. And when deadlines are tight, nobody is sitting there inventing fifty creative ways to break their own endpoint just for fun.

That is where the story changes. Instead of asking “does this request work,” the more interesting question is “what happens when this request stops being polite.” Missing fields, wrong types, oversized payloads, malformed JSON, broken tokens, weird casing, extra data nobody asked for. The kind of input that always shows up in production, usually at the worst possible moment.

That is the gap Rentgen is built for. Not to replace the editor workflow, not to compete with API clients, but to take one working request and push it a bit harder. You copy the cURL, drop it in, and instead of manually crafting edge cases, you get a whole set of variations automatically. Some APIs handle it well. Some respond like they have just seen a ghost. Both outcomes are useful.

The difference is not about features or UI. It is about responsibility. Thunder Client helps you build and verify your API while you are working. Rentgen helps you challenge the assumptions behind that work before you move on. One keeps things smooth. The other makes things slightly uncomfortable. And if you have spent enough time debugging production issues, you already know which one tends to reveal the interesting problems.

The workflow is actually simple when you stop trying to compare them. Use Thunder Client while building. Keep everything close to your code, move fast, get feedback, fix things. Once the request works, take that same request and run it through Rentgen. Now you are no longer testing what you expected. You are testing what you forgot.

That shift matters more than most teams realize. Because a lot of automation is built on top of assumptions that were never properly challenged. You end up with clean test suites that quietly ignore the messy cases. And those messy cases are exactly where bugs like to hide.

So no, this is not Thunder Client vs Rentgen in the usual sense. One is an API client. The other is a reality check. One helps you build. The other helps you find out what you missed before someone else does.

Full article: https://rentgen.io/api-stories/Thunder-Client-and-Rentgen-testing-inside-editor-reality-checking-outside-happy-path.html

Without cURL, Rentgen Doesn’t Exist — But cURL Alone Isn’t Enough

Liudas — Mon, 04 May 2026 14:48:16 +0000

I’ve seen this pattern too many times to ignore. You write a clean cURL request, hit enter, get a nice 200 back, JSON looks good, and suddenly everyone relaxes like the job is done. cURL is brilliant at that moment. It is simple, direct, brutally honest. You send exactly what you wrote and the server responds. No magic, no abstraction, just raw truth. And that’s exactly why developers trust it. If something works in cURL, you know what was sent. But here’s the uncomfortable part: it only proves that one exact request worked once. Nothing more.

Real APIs don’t live in that perfect scenario. Fields go missing, values change, types break, tokens expire, payloads get messy, and clients behave in ways nobody planned for. And suddenly that clean request doesn’t mean much anymore. You could write dozens of variations by hand in cURL, but let’s be honest, nobody wants to sit there crafting broken payloads all day just to see if something explodes.

This is where I ended up building something on top of that idea. Instead of replacing cURL, just extend it. Take one working request and start asking a better question: what happens when this request stops being perfect? That’s the gap. That moment between “it works” and “it actually survives real input.” Turns out that’s where most of the interesting problems live. Inconsistent validation, weird status codes, backend 500s that should never exist, responses that make debugging unnecessarily painful.

The workflow is simple and it makes more sense than pretending one tool can do everything. Use cURL to get the request right. Then take that exact request and push it a bit. Remove fields, break types, stretch boundaries, mess with payloads. Now you’re not testing one scenario anymore, you’re seeing how the API behaves in reality. And that’s a very different picture.

A lot of teams jump straight from a working request into automation. They build clean test suites around clean scenarios and feel safe. But automation built on assumptions is just a faster way to miss things. If you don’t explore the messy cases first, your tests will simply never cover them.

So no, this is not cURL vs anything. cURL stays exactly where it belongs — as the ground truth. But one request proving it works is only half the story. The other half is figuring out what breaks. And that’s where things actually get interesting.

Full version: https://rentgen.io/api-stories/cURL-and-Rentgen-one-proves-it-works-the-other-proves-what-breaks.html

HTTPie vs Rentgen is one of those comparisons that sounds sensible right up until the moment you realise they’re not even playing the same sport.

Liudas — Sun, 03 May 2026 06:41:38 +0000

Yes, both talk to APIs, but so does half the internet, and we don’t compare a terminal tool with a stress test for the same reason we don’t compare a steering wheel with a crash test. HTTPie is there to make requests readable, clean, almost pleasant. You type something that looks like English instead of a cursed cURL command, hit enter, and the API politely responds. It’s fast, it’s human, and it’s exactly what you want when you’re building or debugging something without losing your will to live.

And then, of course, comes the dangerous bit. The request works. The response looks fine. Everyone leans back and says, “good enough.” This is where reality quietly clears its throat. Because that one perfect request doesn’t prove your API is solid, it proves that one carefully constructed scenario didn’t fall apart. Everything else is still a mystery. Missing fields, wrong data types, strange payloads, expired tokens, random whitespace, and all the other things real systems throw at your backend are still waiting their turn.

HTTPie doesn’t pretend to solve that, and it shouldn’t. It does its job properly. It lets you talk to the API like a normal human being instead of fighting with syntax. But it will only ever send what you ask it to send. If you don’t think about edge cases, they don’t exist. If you don’t test something, it remains untested. Simple, honest, slightly terrifying.

This is where Rentgen wanders in, not as a replacement, but as the slightly annoying colleague who asks uncomfortable questions. You take that same working request, drop it in, and suddenly the API is dealing with all the things you didn’t bother to try. Fields disappear, values change, payloads get ugly, and the system is forced to respond to something closer to reality. Sometimes it handles it gracefully. Sometimes it produces errors that make you wonder how this ever reached production. Nothing dramatic, just the usual collection of “we probably should have tested that.”

The difference isn’t power, it’s timing. HTTPie lives in the moment where you build and understand the request. Rentgen lives right after, when you ask whether that understanding was actually complete. One gives you clarity, the other gives you doubt, and you need both if you don’t enjoy debugging things at three in the morning.

Used properly, they fit together perfectly. You build the request with HTTPie, make sure it works, then you let Rentgen make it slightly uncomfortable. Fix what breaks, learn what matters, and only then turn that knowledge into proper tests. That way you’re not automating guesses, you’re automating reality.

HTTPie helps you speak to your API. Rentgen helps you find out what your API says when things stop being polite. Same request, different purpose, no drama required.

Full version here: https://rentgen.io/api-stories/HTTPie-and-Rentgen-first-talk-to-the-API-then-make-it-uncomfortable.html

Insomnia vs Rentgen — powerful API platform vs raw API reality

Liudas — Fri, 01 May 2026 18:41:38 +0000

Insomnia vs Rentgen is one of those comparisons that sounds logical until you actually think about it for more than five seconds. Yes, both deal with APIs, but so does electricity and your toaster, and nobody is comparing those. Insomnia is a proper API platform. You build requests, manage collections, write assertions, run tests, sync with Git, collaborate with teams and generally behave like a responsible adult. It’s structured, repeatable, and absolutely necessary once your API stops being a toy and starts becoming a system.

Rentgen doesn’t even try to compete with that. It shows up earlier, at that suspiciously quiet moment when the first request returns 200 and everyone suddenly decides the job is done. That’s where things usually go wrong. Because one clean request doesn’t prove the API works, it proves that one carefully crafted scenario didn’t explode.

Insomnia works with what you define. If you don’t test missing fields, they don’t exist. If you don’t try invalid data types, wrong casing, broken payloads or boundary values, the system will happily pretend those problems don’t exist… right until production proves otherwise. And production is very good at proving people wrong.

Rentgen flips that around. Instead of asking you to think of every edge case, it assumes you didn’t. You take one real cURL request, drop it in, and suddenly the API is dealing with missing fields, garbage input, weird payloads, and all the things real systems eventually send whether you like it or not. No ceremony, no scripts, just a fast way to see how fragile the endpoint actually is.

The real difference is timing. Insomnia lives in the main workflow. It’s where you build, test, debug, and maintain your API over time. Rentgen lives before that. It’s the uncomfortable reality check before you start writing beautiful automation around assumptions that were never challenged.

And that matters, because a lot of teams go straight from “it works” to “let’s automate it” and end up with test suites that look impressive but quietly ignore half the problem space. Automation based on assumptions is just a very efficient way to be wrong.

Used properly, they sit next to each other perfectly. Build and understand the request in Insomnia, then take that exact request, run it through Rentgen, fix what breaks, and only then turn it into proper tests. That way you’re automating reality, not wishful thinking.

Insomnia helps you build and manage API systems. Rentgen helps you find out what those systems don’t handle yet. Same request, different phase, completely different job.

Full breakdown here: https://rentgen.io/api-stories/Insomnia-vs-Rentgen-powerful-API-platform-vs-raw-API-reality.html

Hoppscotch vs Rentgen? Not really. One sends requests. The other breaks them.

Liudas — Thu, 30 Apr 2026 15:19:34 +0000

There’s a funny moment in every API project.

You send a request.

It returns 200.

JSON looks clean.

Everyone nods.

“Works.”

And that’s exactly where things usually start going wrong.

The clean illusion

Tools like Hoppscotch are brilliant at what they do.

Fast. Lightweight. Open-source.

You send requests, tweak headers, manage collections, debug responses — all the good stuff.

It’s the modern version of “does the API respond?”

And that matters.

Because without a tool like that, you’re basically copying cURL commands between tabs like it’s 2008.

But here’s the uncomfortable part

That one successful request?

It proves exactly one thing:

👉 That exact request worked once.

That’s it.

It says nothing about:

missing fields
wrong data types
extra whitespace
invalid enums
malformed payloads
broken auth
or the classic: “why is this returning 500?”

And that’s not a tooling problem.

That’s just how manual testing works.

Where Rentgen shows up

Rentgen starts right after that “it works” moment.

Not to replace Hoppscotch.

To question it.

You take the same request.

Paste it in.

And suddenly you’re not testing one scenario anymore.

You’re testing dozens.

Fields disappear.

Types change.

Payloads break.

Headers go weird.

And now the API has to deal with reality.

This is where things get interesting

Because APIs behave very differently when input stops being polite.

Some handle it well. Clean 4xx responses, consistent validation.

Others… panic.

500 errors where there shouldn’t be any
inconsistent status codes
HTML responses from JSON APIs (yes, still happens)
validation that works sometimes and then just… gives up

Nothing exotic. Just the boring stuff nobody tests properly.

The real difference

Hoppscotch gives you control.

Rentgen gives you pressure.

One helps you ask a question.

The other slightly messes up the question and watches what happens.

A workflow that actually makes sense

Use Hoppscotch (or any API client) to:

build the request
understand the endpoint
confirm the happy path

Then:

Take that exact request → run it through Rentgen.

Now you're asking a better question:

👉 What happens when this request stops being perfect?

Why this matters

A lot of teams go straight from “200 OK” to automation.

They build test suites around clean scenarios…

and accidentally automate assumptions.

That’s how you end up with beautiful CI pipelines

testing things that were never really explored.

The simple version

Hoppscotch → work with APIs
Rentgen → challenge APIs

Same request.

Different job.

If you want the full breakdown (without me trying to be clever), I wrote a detailed version here:

👉 https://rentgen.io/api-stories/Hoppscotch-vs-Rentgen-API-client-and-API-reality-check-are-not-the-same-job.html

Bruno vs Rentgen — same cURL, very different consequences

Liudas — Wed, 29 Apr 2026 18:04:05 +0000

There is a moment every developer knows.

You take a cURL. Maybe from Swagger. Maybe from logs. Maybe you copied it from the browser like a civilized person. You paste it into Bruno, press “Send”, and it works.

Beautiful response.

At this point, someone leans back in their chair and says: “Looks good. Tested.”

And that, right there, is how bugs quietly book their flight to production.

Bruno is not the problem here. Bruno is actually very good. It does exactly what you expect: you send requests, organize them, keep things in Git, build collections, run flows. It’s clean, fast, doesn’t try to be smarter than you, which is already better than half the tools out there.

But here’s the uncomfortable bit.

Bruno does exactly what you tell it to do.

No more.

So if you didn’t think about removing a required field, it won’t happen. If you didn’t try sending a string instead of a number, nobody will. If you didn’t check what happens when the payload is slightly broken, the API will happily keep that secret until production introduces it to you at full speed.

This is where Rentgen walks in like an annoying inspector who doesn’t trust your “looks fine” attitude.

Because Rentgen starts where Bruno stops.

Not when the request fails. That would be too easy. It starts when the request works — which is precisely when most teams stop thinking. Rentgen takes that same perfectly working cURL and begins doing the things nobody bothers to do manually. It removes fields, breaks formats, stretches values, messes with enums, and generally behaves like the worst possible client your API will ever meet.

And suddenly, things get interesting.

That clean 200 becomes a 500. Validation disappears. Errors make no sense. Status codes start behaving like they were picked randomly by a drunk intern. Nothing catastrophic, nothing dramatic — just a collection of small, embarrassing problems that were always there, quietly waiting.

This is the part nobody likes to admit.

Most API bugs are not genius-level failures. They are laziness, assumptions, and the belief that “it worked once” somehow means “it works”.

It doesn’t.

What it means is that one very specific request, under very polite conditions, did not explode.

Congratulations.

Bruno helps you operate the API. Rentgen questions whether the API deserves to exist in its current state.

They are not competitors. They are different stages of reality.

You use Bruno to get things working. You use Rentgen to see how quickly they stop working.

And if you skip that second part, you end up with automated tests that confidently prove that your happy path still works, while everything else burns quietly in the background.

The sensible workflow is painfully simple. Get your request working in your client. Run it through something that doesn’t trust you. Fix what breaks. Only then write automation.

Anything else is just optimism with better tooling.

If you want the original version without the sarcasm, it’s here: https://rentgen.io/api-stories/Bruno-vs-Rentgen-same-cURL-different-job.html

Same cURL.

Very different outcome.

AI Testing Is Not Magic — You Already Know How to Do It

Liudas — Wed, 29 Apr 2026 15:57:45 +0000

AI is everywhere right now. Everyone is talking about AI testing—more specifically, testing LLMs. We keep hearing that it’s a completely different world, that QA engineers need to reskill, that the main issue is non-determinism, and that testing such systems is nearly impossible. Or that classical testing methods simply don’t apply.

In reality, not really. It’s just overcomplicated.

Long before AI, we already had systems that behaved non-deterministically. If you’ve worked in AdTech, you know exactly what this means. Whether a banner is shown or not, and to whom—it all depended on hundreds of parameters and real-time data. The same input didn’t necessarily produce the same output. In fact, the same input produced different results.

And somehow, we still tested those systems.

In such systems, logic was verified at a lower level—in isolated environments, through unit and integration tests, with clearly defined boundary values. We tested at the edges: with these inputs, the result must be A; with slightly different inputs, the system transitions into another state. The fact that above the boundary there was more variation was not surprising—it was expected. That’s how the system was supposed to behave.

The exact same principle applies to LLM-based systems. But first, let’s put things into perspective.

What Are You Actually Testing?

In most cases, you are testing an AI-powered application or system—not the model itself.

You only need to test the model in two cases:

If your company is building its own model
If you are actually training or fine-tuning the model with your own data (fine-tuning, labeling, humans-in-the-loop, etc.)

In all other cases, you do not need to test the model. Yes, that’s a strict statement—intentionally.

If you’re using OpenAI, Anthropic, or any other cloud model, you are testing the integration. If you’re using an open-source model locally, you are still testing whether it works correctly within your system. That is integration testing. This is a third-party dependency, and the same rules apply as with any other integration.

Separate your application testing from third-party behavior. Mock the model. Build an emulator. Ensure your tests are fast and stable. Your goal is to find when your application fails—not to retest OpenAI.

What About Model Updates?

Of course, you need control. Just like with any integration.

If the model version changes, you need to verify that your use case hasn’t been broken. But this is not model testing in the fundamental sense. It’s regression testing—checking whether the integration still works and whether behavior hasn’t changed in a critical way.

A small regression dataset, a few key scenarios, a sanity check—and move on. We are not testing the model architecture. We are verifying that our system still works.

The Interesting Part — When You Train the Model Yourself

If you’re using an open-source model and fine-tuning it with your own data, then you’re no longer testing the base model—you’re testing your training. In other words, you’re verifying whether you trained the model correctly.

And here, things are much simpler than they appear.

The goal of testing remains exactly the same as always: find where the system fails.

In the case of LLMs, that means:

The model gets stuck
It produces nonsense
It starts hallucinating
It becomes unstable with certain inputs

Where does this happen? Most often—at the edges.

Where data is scarce. Where classes overlap. Where context is ambiguous. That’s where the model behaves more randomly. And that’s expected.

A Practical Testing Approach

The method is simple:

Take a boundary case
Run it hundreds of times
Measure the percentage of correct responses
If the percentage meets your defined threshold—the test passes. / If not—the test fails.

The fix? Not code changes. You need more or better-quality training data.

Now take clear, non-boundary cases where the answer should be almost always correct. Run them hundreds of times again. The expected result is close to 99–100%.

If you see significant variation here, you have a problem with training and/or data quality. This is not rocket science—it’s basic statistical stability testing.

When Everything Becomes Part of a System

Once the AI model becomes part of a larger system, additional challenges appear—performance, monitoring, real-world data, unexpected inputs. But this is just system-level testing—operational testing.

Does the system work under real conditions?
Does it handle load?
Do fallback mechanisms work?
Security, etc.

Fundamentally, this is no different from testing any other complex system.

Final Thought

AI testing is not magic.

LLM non-determinism is not a revolution in testing, nor is it a problem. We have already tested complex, probabilistic systems before.

The key is to clearly separate:

where you are testing your application
where you are testing integration
and where you are actually testing your data

Everything else is the same: the same principles, the same goals, the same discipline.

Of course, if you are building your own AI model from scratch—that’s a different topic.

I’ll leave that for another time.

Rentgen vs Apidog — not competitors, different moments

Liudas — Sun, 26 Apr 2026 14:33:34 +0000

People often try to compare Rentgen with tools like Apidog. On paper it sounds logical — both are related to APIs. But in practice, they solve completely different problems.

Apidog is a full API development platform. You design APIs, mock them, document them, collaborate with your team, write assertions, and integrate everything into CI/CD. It’s a system you live in when building and maintaining APIs.

Rentgen is not that. And it doesn’t try to be.

Rentgen flow: cURL in, tests out
One request in. Reality instead of assumptions.

The moment everyone skips

There is a specific moment in API development that almost nobody talks about. A developer writes an endpoint, sends a request, gets a response, and moves on. Maybe they check for 200 OK, maybe they look at the response body. And then comes the classic line: “I tested it. It works.”

That’s where most problems are already hiding. Not because someone did something wrong, but because only the expected scenario was tested. Everything else is still unknown.

Tools like Apidog come in after that — to formalize behavior, add structure, build proper test suites. But the initial assumption is already baked into the system.

Rentgen exists exactly at that earlier step.

What Rentgen actually does

Instead of writing tests, you take a real request — the same cURL you would paste into any API tool — and run it through Rentgen. It expands that single request into a wide range of variations that reflect real-world usage: invalid inputs, boundary values, malformed payloads, and unexpected combinations.

Then you see how the API actually behaves. Not what it was designed to do, but what it really does under imperfect conditions.

Where the difference shows

This is where the gap becomes obvious. Instead of discovering new features, you start seeing the same patterns over and over: inconsistent status codes, unexpected 500 errors, validation happening too late, inputs that should fail but pass, or payloads that break things entirely.

These are not rare edge cases. These are common problems that only show up when you stop testing just the happy path.

We’ve seen this repeatedly across real-world APIs — including large, production systems. The interesting part is that many of these issues are not caught by traditional automation because automation usually reinforces expected behavior instead of challenging it.

Apidog builds. Rentgen questions.

Apidog is about building, structuring, and managing APIs properly. It gives teams control and collaboration across the entire lifecycle.

Rentgen does something much simpler. It questions assumptions. It asks what happens when real input doesn’t match what was expected.

That question usually comes too late — after tests are written or even after release. Rentgen moves it earlier.

Not a replacement. A missing layer.

This is why these tools are not competitors. You don’t replace Apidog with Rentgen. You run Rentgen before you fully trust your API.

Fix the obvious issues early, then move into structured testing, automation, and CI/CD with something that actually behaves correctly.

Why this matters

Most teams don’t fail because they lack tools. They fail because they trust the first working response too quickly.

One request works, so everything “feels done”. But one request only proves one thing works. Everything else is still unknown.

That’s the gap Rentgen is built for — not to replace existing tools, but to make sure that when you say “it works”, you actually know what that means.

Postman VS Bruno

Liudas — Tue, 21 Apr 2026 05:29:55 +0000

While Postman and Bruno argue who’s the better API client…

Rentgen is not even in that category.

Because the problem is not sending requests.
The problem is understanding what your API actually does.

👉 API clients = send requests
👉 Rentgen = shows real behavior

One request → 50–200 test cases → real edge cases → real bugs

That’s the difference.
Automation before automation.

👉 https://rentgen.io

Most APIs don’t break on happy paths

Liudas — Mon, 20 Apr 2026 11:32:07 +0000

Before Rentgen
Everything looks fine.
Status: 200 ✅

After Rentgen
Reality hits. 💥

Most APIs don’t break on happy paths.
They break on everything else.

Paste one request → see what actually happens.

👉 https://rentgen.io

New Rentgen Release v1.20.0 🚀

Liudas — Mon, 06 Apr 2026 17:23:51 +0000

Release v1.20.0 🚀

👉 Project export / import (this is the main one)
No accounts. No cloud. No data leaving your machine.
Export your project → get a file → put it anywhere: Dropbox, GitHub or any shared folder. Your team (5, 100 or 10 000 people) just takes it and uses it. At 0 cost. And No sync back to server. No logins. No vendor lock-in. No data exposure. Just a file. Full control.

👉 New test: invalid token. We take your Authorization and break it.
Expected: 401
Reality: often not.

👉 Response time. Now visible per request and per test. No extra tools. No guessing.

Paste a request. See what breaks. Automation before automation.

New release Rentgen.io