Skip to content

feat: add OpenAPI 3.2 support#479

Open
aaronlippold wants to merge 2 commits into
ahx:mainfrom
aaronlippold:feat/openapi-3.2-support
Open

feat: add OpenAPI 3.2 support#479
aaronlippold wants to merge 2 commits into
ahx:mainfrom
aaronlippold:feat/openapi-3.2-support

Conversation

@aaronlippold
Copy link
Copy Markdown

Summary

  • OpenAPI 3.2.0 (released Sep 2025) uses the same JSON Schema dialect as 3.1 — no breaking changes, only additive features (structured tags, streaming support, OAuth device flow)
  • The version regex in Builder#detect_meta_schema now accepts 3.2.x versions and routes them through the existing 3.1 codepath
  • Added test verifying a 3.2.0 document parses correctly with title and path extraction
  • Updated README and CHANGELOG

Test plan

  • New test parses a 3.2.0 document without error passes
  • Full suite: 566 examples, 5 failures (all 5 pre-existing on upstream main — verified by running clean main checkout)
  • No new failures introduced

Fixes #469

OpenAPI 3.2.0 uses the same JSON Schema dialect as 3.1 — no breaking
changes, only additive features (structured tags, streaming, OAuth
device flow). The version regex in Builder#detect_meta_schema now
accepts 3.2.x versions and routes them through the existing 3.1
codepath.

Fixes ahx#469

Authored by: Aaron Lippold<lippold@gmail.com>
@aaronlippold aaronlippold requested a review from ahx as a code owner May 26, 2026 13:14
Copilot AI review requested due to automatic review settings May 26, 2026 13:14
Copy link
Copy Markdown

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Note

Copilot was unable to run its full agentic suite in this review.

Adds OpenAPI 3.2 support by treating 3.2 documents as using the same JSON Schema dialect handling as OpenAPI 3.1, and updates tests/docs accordingly.

Changes:

  • Extend meta-schema/dialect detection to accept openapi: 3.2.x
  • Add a spec asserting a 3.2.0 document parses successfully
  • Update README + changelog to document 3.2 support

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 3 comments.

File Description
spec/definition_spec.rb Adds coverage verifying a minimal OpenAPI 3.2 document parses and exposes expected properties
lib/openapi_first/builder.rb Expands version matching so 3.2 uses the OpenAPI 3.1 JSON Schema dialect path
README.md Documents support for OpenAPI 3.2
CHANGELOG.md Notes the new OpenAPI 3.2 support and references the motivating issue

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

version = document['openapi']
case version
when /\A3\.1\.\d+\z/
when /\A3\.[12]\.\d+\z/
Comment thread README.md
# openapi_first

openapi_first is a Ruby gem for request / response validation and contract-testing against an [OpenAPI](https://www.openapis.org/) 3.0 or 3.1 Openapi API description (OAD). It makes an APIFirst workflow easy and reliable.
openapi_first is a Ruby gem for request / response validation and contract-testing against an [OpenAPI](https://www.openapis.org/) 3.0, 3.1, or 3.2 Openapi API description (OAD). It makes an APIFirst workflow easy and reliable.
Comment thread CHANGELOG.md

## Unreleased

- Add OpenAPI 3.2 support. OAS 3.2 uses the same JSON Schema dialect as 3.1 (no breaking changes), so the 3.1 codepath handles it correctly. Fixes #469.
bin/setup runs bundle install but doesn't initialize the
spec/data/train-travel-api submodule. Developers cloning the repo
and running bin/setup then bundle exec rake see 6 test failures
from missing fixture files. Adding git submodule update --init
--recursive to bin/setup prevents this.

Authored by: Aaron Lippold<lippold@gmail.com>
@ahx
Copy link
Copy Markdown
Owner

ahx commented May 26, 2026

Hey @aaronlippold, thanks for looking into this. I was always struggling a bit with OAS 3.2, because I did not really understand what changes are included and what openapi_first needs to implement in order to support it. Here are some things from the release page where I think we need to do something:

  1. discriminator and the new field defaultMapping – Does that just work?
  2. "Additions to support multipart media types"
    2.1 New itemSchema field
    2.2 New fields prefixEncoding and itemEncoding
  3. Support for additional HTTP methods – Under an additionalOperations entry in a Path, use any other methods not listed as keys using the correct capitalization, e.g. LINK. Do NOT add HEAD under this, use the existing sibling head.

I have listed these points in the related issue as well.

@aaronlippold
Copy link
Copy Markdown
Author

aaronlippold commented May 26, 2026 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

OpenAPI 3.2 support

3 participants