DEV Community

Vigneshwaran Manivannan
Vigneshwaran Manivannan

Posted on

Why Testing Only 200 OK Is Lying to Yourself

#webdev #testing #opensource #microsaas

And How I Built “Status Code as a Service” for Fun
Most applications work perfectly. Until the backend stops returning 200 OK?

As developers, we spend a lot of time building and testing the happy path — APIs returning 200 OK, clean JSON responses, smooth UI flows. But real-world systems don’t live in that world.

They live in a much messier place:

404 429 500 503
Enter fullscreen mode Exit fullscreen mode

And if your frontend or client code has never seen those responses during development, it’s usually not prepared for them in production.

The Problem With “Mocking Success”
In many projects, error handling is tested in one of three ways:

  • Not tested at all
  • Manually faked by changing code
  • Mocked with static responses

All three approaches miss something important: real HTTP behavior.

HTTP status codes are not just numbers. They influence:

Retry logic, UI state transitions, Caching behavior, Rate limiting flows, User experience under failure.

Mocking a 500 inside application code is not the same as receiving an actual 500 from an API.

A Small Side Project (Inspired by “No as a Service”)
While exploring this problem, I came across the fun project No as a Service, which simply returns “no” via an API.

That sparked a thought:

What if we had something similar — but for HTTP status codes?

  • Not a serious product.
  • Not a startup idea.
  • Just a small, learning-focused side project.

That’s how Status Code as a Service (SCaaS) started.

What Is Status Code as a Service?
Status Code as a Service is a lightweight HTTP API that returns real HTTP status codes on demand.

It supports:

  • Deterministic responses (/status/404)
  • Random status codes
  • Weighted distributions (more realistic than pure randomness)
  • Category-based responses (success, client error, server error)

The idea is simple:
let your frontend or API client experience real failures during development.

So instead of returning them directly, the API simulates them safely by:

  • Returning 200 OK
  • Including the intended status code in the response payload
  • It’s a small detail — but it highlights how HTTP behavior can differ from theory once real infrastructure is involved.

Why This Was Useful (Even as a “Fun” Project)
Even though this started as a casual experiment, it turned out to be genuinely useful for:

  • Testing frontend error states
  • Verifying retry and backoff logic
  • Understanding how APIs behave under rate limits
  • Simulating partial outages
  • Learning how CDNs and proxies treat HTTP responses

Most importantly, it reinforced one idea:

If you don’t test failure, you haven’t really tested your system.

Keeping It Simple
The project is intentionally minimal:

  • Stateless
  • No database
  • Node.js + Express
  • Clear, predictable behavior
  • It’s open-source, easy to run locally, and easy to deploy.

If someone finds it useful — great.
If not — it was still a valuable learning experience.

Final Thought
Testing only 200 OK responses gives a false sense of confidence.

Real systems fail.
Networks fail.
APIs fail.

Your application should be ready for that — before production finds out for you.

GitHub: https://github.com/Vigneshmani28/statuscode-as-a-service

Live url: https://scaas.onrender.com/

My portfolio: https://vigneshdev.in

Top comments (0)