openapi-preprocessor VS oasdiff

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.

We will use an open-source GitHub action, oasdiff-action, based on the tool ‘oasdiff.’

Nice, Have you come across this tool oasdiff from the article? It may help with detect API breaking changes in swagger

While you might wish that pull request reviewers would spot any breaking changes, relying solely on this method is not certain and might lead to failure eventually. If you have OpenAPI/Swagger documentation for your APIs, these can be version-controlled and included in a CI pipeline. APISIX doesn't natively support direct integration with version control systems like Git for API specification changes. However, you can set up a process outside APISIX. Tools like Oasdiff or Bump can identify changes in API specs, and trigger a CI pipeline (add GitHub Action) that runs tests against the route endpoints in APISIX to ensure no breaking changes are introduced.

Now that we have a way to lookup our API’s behavior with Git, we can start testing for breaking changes between versions of our API. We’ll be using Optic (an open source tool I created) to do just that. If you are looking for other options I recommend https://github.com/OpenAPITools/openapi-diff or https://github.com/Tufin/oasdiff.

2. Delete the API at the sunset date or later

People seem to want such a process in order to prevent breaking-changes.

I wrote a diff tool for OpenAPI spec which supports detection of breaking-changes and I recently extended it to support this process and a bit more.

Now I'm looking for feedback.

Proposed Solution (currently in Beta): https://github.com/Tufin/oasdiff#non-breaking-removal-of-deprecated-resources

Related requests: