api-firewall VS openapi-preprocessor

In this case, you can try to block such tokens as strings inside incoming API requests. For unmanaged APIs, you can install the OSS API-firewall proxy https://github.com/wallarm/api-firewall

The product is open source, available at DockerHub and already got 1 billion (!!!) pulls. To support this project, you can star the repository. Check it out: https://github.com/wallarm/api-firewall

Open source API firewall https://github.com/wallarm/api-firewall

I use a mixed approach for OpenAPI, but not bidirectional.

I have OpenAPI pieces generated from my Go source code (comment, types, function signatures) as JSON.

I also have a manually-edited master YAML document that refers to generated bits via $ref links.

I then use openapi-preprocessor [1] (disclaimer: I wrote it) to produce a final openapi.json file which is committed in the repo.

When I want to extend the API in a spec-first process, I can add the new routes manually in the YAML file. When I do the implementation I replace the manual bits by the generated one when they are ready. When committing I can check the diff of openapi.json to verify I'm not losing in the process.

[1] https://github.com/dolmen-go/openapi-preprocessor

Bundling for OpenAPI specification has long been a need for authors to allow to reduce duplication, and to allow to split a big specification in multiples files, but publish a single one.

A few years ago I've written a tool to fit that niche: https://github.com/dolmen-go/openapi-preprocessor

https://github.com/dolmen-go/openapi-preprocessor

I have now to tweak it (well, it will be a major rewrite) to handle $ref relative to $id instead of the file location.