Why ReṼoman?

An agent — an AI agent, or your own JVM code acting as one — needs two things to act on APIs: something that executes a workflow of interdependent calls deterministically, and structured context about what happened. ReṼoman is the middleware that provides both. The pain below is why that middleware layer is needed.

The Problem

  • The majority of JVM SaaS applications are REST-based. But the API automation is done through a Mul-T-verse of Integration/Functional tests, E2E tests and Manual tests, each with its own frameworks, tools, and internal utilities, testing almost the same code flow.

  • These custom alien automation frameworks, often built using low-level tools like REST Assured, are specific to a service or domain and are rigid to reuse, extend, and difficult to maintain.

  • This automation competes on cognitive complexity and learning curve with the Prod code, and mostly, automation wins.

  • After a point, the API orchestration/automation may deviate from its purpose of augmenting real end-user interaction and turns into a foot-chain for development.

ReṼoman keeps cognitive complexity low; custom automation frameworks push it high

The Solution

Contrary to these custom frameworks, almost every team already uses Postman for manual testing their APIs. A Postman collection captures a lot about your APIs and the order in which they run for manual testing — it is, in effect, executable API metadata in a structured schema. Leveraging that metadata directly mitigates writing a lot of code, because the manual steps are the workflow you want to automate.

  • How productive would it be if you could plug in the executable API metadata you already authored for manual testing and execute it through your JVM tests?

  • How about a middleware layer that executes that graph for you — promoting low code and low cognitive complexity, and striking a balance between flexibility and ease of use?

ReṼoman is that middleware. It reads the executable API metadata you already have — today serialized in the Postman V2/V3 schema — and executes the graph on the JVM. See Executable API Metadata for the data format, Type Safety for how it bridges JVM types and JSON, and Hooks for plugging custom JVM code into the run.

A runner is not middleware

You might reach for Newman or the Postman CLI to run a collection from the command line. They overlap with ReṼoman only at the narrow point of "execute a collection" — the similarities end there. A runner cannot be an orchestration engine inside your JVM or agentic stack:

  • Built for Node, not the JVM. Newman and the Postman CLI run on Node and cannot execute within a JVM. Even with a hacky shell-out, there is no easy way to measure code coverage or assert results on your JVM stack.

  • JVM-native. Built for the JVM, ReṼoman fits naturally within your current JVM stack — coverage, assertions, and all.

  • Type safety. Its Type Safety bridges the gap between strongly-typed JVM code and flexible JSON, so payloads come back as POJOs you can assert on directly.

  • Richer execution model. It has more features, like dynamic pre/post-step hooks that let you plug custom JVM code in between execution steps. The Rundown is far richer in execution information than the newman/postman-cli reports — and that Rundown is the structured Context Information described in Agentic API Orchestration.

In short, a runner emits a pass/fail report; middleware executes an API-Graph, resolves the dependencies between steps, and returns structured Context Information the caller — your JVM code, or an agentic Node — builds on. See Agentic API Orchestration for the identity in full, and Applications for what it unlocks.

Roadmap, not present-tense. ReṼoman is not meant to stay tied to a single input schema. The direction is to support more authoring formats — JetBrains HTTP Client, Bruno, and others — for added versatility. This is future direction, not a capability that ships today; today the engine reads executable API metadata in the Postman V2/V3 schema.