Skip to content

Conversation

@Traderjoe95
Copy link

Motivation:

In the current implementation, it is impossible to use OpenAPI schemas that have media types which are unsupported by the library. In our concrete use case, we have multiple SSE endpoints (media type text/event-stream) that are not supposed to be validated, but vertx-openapi still refuses to parse the contract, as the media type is none of the predefined supported media types.

In this PR, I extend the OpenAPIContractBuilder to allow users to specify additional supported media types, as long as they provide a mapping of those media types to JSON (for schema validation) or specify that the media type should be treated as an opaque string and remain unchecked.

The main user-facing change are two new methods in OpenAPIContractBuilder and a new interface for constructing custom ContentAnalysers:

  • OpenAPIContractBuilder.registerSupportedMediaType registers a media type together with a ContentAnalyserFactory that provides a JSON mapping of that media type
  • OpenAPIContractBuilder.registerUncheckedMediaType registers a media type as an opaque unchecked string
  • ContentAnalyserFactory creates content analysers. Users can create their own implementations of ContentAnalyser and a matching factory in order to support custom media types.

Internally, a map of additional supported media types is passed down through the OpenAPIContractImpl hierarchy at construction time. The MediaTypeImpl class stores a reference to the matching custom ContentAnalyserFactory, if any.

All changes are tested and documented.

@Traderjoe95
Copy link
Author

This is a duplicate of #101, which has been stale for a while. If you want, we can merge both PRs. In any case, I would like to see this feature soon, as it blocks our Vert.x 5 migration at this time.

@pk-work
Copy link
Contributor

pk-work commented Sep 9, 2025

Hi @Traderjoe95, thank you for your interest in Vert.x OpenAPI. I admit that #101 has been stale for while, but I'm in regular contact with @lukasjelonek. Maybe he will find time in the next weeks to continue his work, because we discussed already everything upfront and I reviewed his proposal in detail.

But I' glad that you also come up with a proposal, in case @lukasjelonek will not be able to continue with his work.

If you have Discord, I would like to offer you the opportunity to contact me there if you make such a big change again. Then we can coordinate some things in advance to keep the effort as low as possible.

@pk-work
Copy link
Contributor

pk-work commented Sep 19, 2025

@Traderjoe95 could you please check if #118 will meet you requirements? Then I would close this PR.

@Traderjoe95
Copy link
Author

LGTM, thanks, I'm excited to see this released 👍

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.

2 participants