ApiTestSpark: OpenAPI Became Implementation Context

The Project Took an Unexpected Turn

A few weeks ago, I wrote about packaging ApiTestSpark as a React-in-NuGet API test harness. The original goal was deliberately modest. I wanted a lightweight, modern API testing experience that could be packaged directly into an ASP.NET Core application.

The appeal was that the testing surface could travel with the application instead of becoming another thing to deploy, configure, or remember to keep in sync.

The technical details are in the repository and the change log, so I will not repeat them here. What interests me now is what happened after the first release, because the project did not stay in the mental box I had built for it.

I still think of it as an API tester, but the remote API work started to expose a broader problem around how quickly a developer can understand an unfamiliar contract.

A Problem I Have Been Trying to Solve for Years

I have spent a large part of my career building APIs, integrating APIs, documenting APIs, and helping other developers consume APIs. Like most developers, I have accumulated a familiar collection of tools along the way: Swagger UI, Postman, custom test harnesses, wiki pages, curl commands, internal documentation portals, generated SDKs, and the occasional README that somehow becomes the most important artifact in the system. Every one of those tools solves part of the problem, but I keep coming back to the same question: how do I understand this API as quickly as possible?

That is not only a question about which endpoints exist, which parameters are required, or which schema comes back from a request. Those details matter, but they are not the whole picture. The harder question is how the API is intended to be used, especially when the contract is technically correct but the workflow is still something the developer has to infer.

That distinction has become more important as I have spent more time building client applications and working with AI coding assistants. Endpoint documentation is useful, but implementation work needs something more textured than a list of routes. It needs realistic examples, workflow shape, error behavior, naming patterns, and enough context to reduce the number of guesses the developer has to make.

The same is true for AI-assisted development. A model can read a contract, but the quality of the work improves when the contract is paired with examples that show how the system behaves in practice.

The Feature That Changed My Thinking

After the initial release of ApiTestSpark, I added support for remote APIs. At first, it felt like a natural enhancement. If the tool could read an OpenAPI document from a local application, why not let it consume OpenAPI documents from remote systems as well? I expected that to be a convenience feature, but it turned out to be more interesting than that.

I started connecting public APIs simply to see what the tool could derive from their contracts. A reasonably written OpenAPI document could generate navigation, request forms, typed body scaffolds, response expectations, and a surprising amount of user experience. It was not only exposing endpoints. It was creating a guided path through the shape of the system.

The more APIs I connected, the more I realized OpenAPI was doing more than documenting an API. A good contract gave the tool enough information to support discovery, exploration, navigation, and a fair amount of learning without me designing those experiences by hand.

That made me rethink how narrowly I had been treating OpenAPI. For years, I had mostly seen it as documentation metadata. Useful metadata, certainly, but still documentation. ApiTestSpark made the contract feel more active than that. It became an input into how developers learn, test, and eventually implement against an API.

The DevSpark Connection

Around the same time, I was working heavily with DevSpark and AI-assisted development workflows. That is where the ApiTestSpark work started connecting to a larger pattern.

One thing I kept discovering was that simply giving an AI coding assistant an OpenAPI document was not always enough.

In theory, it should be. The contract contains endpoints, schemas, parameters, responses, and descriptions. For a well-structured API, that is a lot of information.

In practice, I kept finding myself doing the same extra step. I would review the contract, execute a request, capture a real response, and then give that response to the AI. The quality of the generated code would immediately improve.

The AI was no longer working from schema alone. It had realistic payloads, field usage, nullable behavior, and relationships that were technically present in the contract but easier to understand from an actual response. The pattern repeated often enough that I stopped treating it as an isolated observation. When I replaced a guess with an example, the generated solution usually improved.

That has influenced how I think about software development in the age of AI. The conversation often centers on the model: which model is better, which model writes cleaner code, which model has the largest context window. Those questions matter, but my experience keeps pulling me toward the quality of the information we give the model in the first place.

Better Context, Better Software

The more I work with AI-assisted development tools, the more I find myself paying attention to context before prompts. Model choice still matters, but the quality of the input material often has a bigger effect than we give it credit for.

The inputs around the code matter. Specifications, examples, workflows, and documentation all reduce the number of invisible decisions that happen in a developer's head and never make it into the code.

All of these things matter for humans. They matter for AI coding assistants too, because an assistant can produce something plausible from incomplete context. The question is whether that output is plausible in the abstract or grounded in the system I am actually building. That is where ApiTestSpark started to change for me.

The original goal was building an API test harness. The more interesting opportunity may be helping developers understand APIs faster, because understanding comes before testing, implementation, integration, onboarding, and code generation. Testing an endpoint is useful, but understanding how a set of endpoints forms a workflow is more useful.

That shift has me looking at the API contract differently. I am paying more attention to whether the contract helps a new developer find the intended workflow, whether an AI coding assistant gets enough implementation context, and where examples can clarify behavior without turning every API into a separate documentation project.

Those questions feel more relevant as AI becomes part of the software delivery process. The API contract is no longer only something a developer reads before writing code. It can also become part of the context that shapes generated clients, tests, integrations, and documentation.

What Started as an API Tester

This is the point where I had to be careful with ApiTestSpark. There is a tempting path where a small API tester becomes a full API platform. Collections, environments, authentication profiles, mocking, load testing, monitoring, documentation publishing, team workspaces, generated SDKs, and lifecycle governance all start looking adjacent. Many excellent products already live in that space, and I am not trying to rebuild them.

The areas that do interest me are closer to developer experience and implementation context. I am interested in lightweight ways to help a developer, or an AI coding assistant, move from "I have an OpenAPI document" to "I understand how to use this API in a real workflow."

That might include collections of remote APIs. It might include enhanced onboarding experiences. It might include lightweight metadata layered on top of OpenAPI. It might include guided workflows, richer examples, AI-assisted documentation, or feature-oriented API exploration.

The important part is the direction, not the feature list. ApiTestSpark should not become bigger simply because bigger is possible. It should become more useful by staying close to the original friction: helping me understand and test APIs faster while I am building real software.

Implementation-Readable APIs

OpenAPI already made APIs machine-readable in a meaningful way. That was a significant step forward, and it continues to matter. A contract that can drive documentation, code generation, validation, and testing is far better than a hand-maintained endpoint list.

But I am starting to think there is another layer worth exploring: making APIs easier to read from an implementation point of view.

By that, I do not mean adding more prose to every operation description. I mean making the intended use of the API easier to infer from the artifacts around it: examples, workflow groupings, naming consistency, error shapes, real responses, and even the order in which a developer discovers endpoints.

An implementation-readable API gives a human enough context to build the right thing without a long archaeology project. It also gives an AI coding assistant more concrete evidence and fewer gaps to fill with guesses.

This is where ApiTestSpark and DevSpark feel connected in my own work. DevSpark explores better software through specifications, planning, governance, and implementation guidance. ApiTestSpark is beginning to explore the same idea through API contracts, examples, workflows, and developer onboarding.

Both projects started with practical problems, and both are being used to build real software today. The common thread is context: the better the context, the fewer assumptions I have to clean up later.

Looking Ahead

I do not know yet exactly where ApiTestSpark goes next, and I am trying to let that uncertainty be useful rather than rushing to brand the project as something larger than it is.

For now, the work is still grounded in a practical loop: connect an API, understand its contract, execute real requests, inspect real responses, and use that evidence to build better integrations. That is enough of a center of gravity to guide the next few decisions.

What has changed is my understanding of the problem. I thought I was building a better way to test endpoints. I may also be building a better way to turn API contracts into implementation context. That feels like a more interesting continuation of the original idea, and like the kind of discovery that only happens after the first version is real enough to push back.

That is the part I want to keep watching. The model matters, but the surrounding context may be what determines whether the work feels grounded in the actual system or just technically plausible.

Explore More

• API Test Spark: React in NuGet for .NET 10 APIs - The first ApiTestSpark article, covering the original package boundary and local API testing goal.
• DevSpark in Practice: A NuGet Package Case Study - A related look at how structured specifications shape real package development.
• DevSpark: The Evolution of AI-Assisted Software Development - The broader thread connecting requirements quality, context, and AI-assisted software delivery.
• Building MuseumSpark - Why Context Matters More Than the Latest LLM - A companion case study on why context often matters more than model choice.