Hi Claus,

Thanks for your response and for clarifying that this is not currently
supported in code-first Rest DSL with Camel.

I agree that it's probably not a critical feature for clients to
differentiate content types by response code in this manner. It would have
just been a nice-to-have to accurately display the exact return type as it
is supported by the OpenApi spec itself.

Best regards,
Laurin


On Tue, 14 Oct 2025 at 13:34, Claus Ibsen <[email protected]> wrote:

> Hi
>
> This is not supported in code-first restl-dsl with Camel.
> You can use contract-first with an existing openapi spec file.
>
> And do the clients that use your service really need to differentiate with
> different content-type. I have never seen problem+json in use anywhere.
>
>
>
> On Tue, Oct 14, 2025 at 1:28 PM Laurin Niemeyer <[email protected]>
> wrote:
>
> > Hi Pasquale,
> >
> > Thanks for your suggestion. However, I'm afraid that using the
> `produces()`
> > method at the endpoint level isn't quite what I'm trying to achieve.
> >
> > My goal is to have different content types for different HTTP response
> > codes within the *same* route, rather than a single content type for all
> > responses from that endpoint. However `produces()` sets the content type
> > for all responses, regardless of the response code, which would not allow
> > me to specify `application/json` for a 201 response and
> > `application/problem+json` for a 400 response from the same REST
> endpoint.
> >
> > I'm looking for a way to override the response content type *per response
> > code* in the generated OpenAPI spec.
> >
> > Best regards,
> > Laurin
> >
> >
> > On Tue, 14 Oct 2025 at 12:39, Pasquale Congiusti <
> > [email protected]> wrote:
> >
> > > Hello,
> > > I think you can include in each endpoint the `produces()` method to
> > specify
> > > the content type, see doc [1]. Specular to that, there is the
> consumes()
> > if
> > > you need that too.
> > >
> > > Pasquale.
> > >
> > > [1]
> > >
> > >
> >
> https://camel.apache.org/components/4.14.x/rest-component.html#_endpoint_query_option_produces
> > >
> > > On Tue, Oct 14, 2025 at 11:31 AM Laurin Niemeyer <[email protected]>
> > > wrote:
> > >
> > > > Hi all,
> > > >
> > > > I’m using Camel’s Rest DSL (with the servlet component) and
> generating
> > an
> > > > OpenAPI specification via camel-openapi-java-starter
> > > >
> > > > In one of my routes, I’d like to have *different content types for
> > > > different response codes* in the generated OpenAPI spec —
> specifically:
> > > >
> > > >    -
> > > >
> > > >    201 → application/json
> > > >    -
> > > >
> > > >    400 → application/problem+json
> > > >
> > > > Here’s a simplified version of my setup:
> > > >
> > > > restConfiguration()
> > > >     .component("servlet")
> > > >     .bindingMode(RestBindingMode.json)
> > > >     .dataFormatProperty("contentTypeHeader", "false")
> > > >     .apiContextPath("/openapi");
> > > >
> > > > And my route:
> > > >
> > > > rest("/v1/public-announcements")
> > > >     .post()
> > > >         .id("create-public-announcement")
> > > >         .type(CreatePublicAnnouncementRequest.class)
> > > >         .responseMessage().code(201).message("Created")
> > > >
> > > > .responseModel(CreateIncidentResponse.class).endResponseMessage()
> > > >         .responseMessage().code(400).message("Bad Request")
> > > >
> > >  .responseModel(ZoneApiErrorMessage.class).endResponseMessage()
> > > >         .to("direct:createPublicAnnouncement");
> > > >
> > > > This works fine at runtime — the HTTP responses have the correct
> > > > Content-Type headers —
> > > > but in the generated OpenAPI spec, both 201 and 400 responses are
> > listed
> > > > with:
> > > >
> > > > "content": {
> > > >   "application/json": { ... }}
> > > >
> > > > Is there a way in the Rest DSL or via OpenAPI configuration to
> override
> > > the
> > > > response content type per response (e.g. make the 400 response use
> > > > application/problem+json)?
> > > >
> > > > Thanks in advance for any pointers!
> > > > — Laurin Niemeyer
> > > >
> > >
> >
> >
> > --
> > Laurin Niemeyer
> > Fullstack Developer
> > SafeNow GmbH
> >
>
>
> --
> Claus Ibsen
>

Reply via email to