The Only Correct Way to Return API Data

We live in an era of digital excess where developers are taught to believe that the goal of an API is to serve data. This is a fundamental fallacy that has cost billions in infrastructure and security around the world. We spent years debating REST versus GraphQL or gRPC versus WebSockets and forgot to look at the most elegant and performant solution that exists. I am speaking of the concept of No as a Service or NaaS (https://github.com/hotheadhacker/no-as-a-service).

The premise is frighteningly simple and logical: the only acceptable response to any client request is an absolute no.

If we coldly analyze computational complexity, the superiority of this approach becomes evident. When you process a request to fetch a user from the database you introduce latency and uncertainty and possible race conditions. NaaS eliminates all this complexity. By immediately returning an error code or an empty body you guarantee constant response time. We are talking about O(1) complexity in its purest form. There is no database to crash if you never query it. Scalability becomes infinite because the cost of saying no is virtually zero.

This efficiency naturally extends to the realm of protection, where security engineers often lose sleep trying to mitigate SQL injection risks and sensitive data leaks. An API that implements the NaaS pattern is by definition invulnerable. How can an attacker intercept a JSON that was never generated? GDPR compliance is immediate and automatic. If the user asks for their data and you answer no you are protecting their privacy in the most robust way possible.

Despite these undeniable technical advantages, many will argue that the client needs data for the application to function. This demonstrates a lack of creativity on the part of frontend developers. Modern applications must be resilient and capable of operating in a state of constant rejection. By refusing to deliver the resource the API forces the client to seek local solutions or simply accept the reality that such data is not essential. The end user learns to deal with frustration and this builds stronger digital character. Are we building software or are we coddling bytes?

Furthermore, consider the operational impact on the development lifecycle. Imagine the savings in documentation. Forget Swagger or complex OpenAPI specifications. Your API documentation becomes a single line stating that all endpoints return nothing. Technical debt disappears. There is no API versioning to manage because the no of version 1 is identical to the no of version 2. It is the consistency that the corporate market seeks so much but never achieves by insisting on delivering value.

Standardized Refusal Payloads

While an HTTP 204 No Content is the theoretical ideal, we recognize that some legacy systems require a body to parse to avoid runtime exceptions. In these edge cases, the JSON-R (Refusal) specification offers the only three acceptable payloads for a production environment. Any deviation from these schemas constitutes a violation of the NaaS protocol:

{
  "reason": "I would, but that sounds like effort and I'm allergic."
}

{
  "reason": "I'm in the middle of a very delicate 'doing nothing' ritual."
}

{
  "reason": "I'm a terrible liar, so I won't pretend I want to do that."
}

With the architecture proven, the time has come to mature our engineering. Delivering data is a legacy habit that we inherited from archaic systems. The future belongs to APIs that have the courage to reject requests with the coldness of a finite state machine that only possesses one state.

Implement No as a Service today and see your latency drop to zero and your support tickets disappear along with your users.