nelmio/NelmioApiDocBundle

[Question]: Is it possible to configure a different serializer per endpoint?

Closed this issue · 3 comments

Version

4.24.0

Question

I have a project using FOSRestBundle and want to switch new endpoints from JMS to Symfony Serializer. To have the correct types in the API docs inferred from the new models while not breaking old ones, I'd basically would need to be able to disable nelmio_api_doc.models.use_jms for new endpoints only.

I also asked a similar thing via symfony/symfony#58348

Any ideas or would a contribution also be accepted if this is currently impossible?

Additional context

No response

Fyi it looks like I'll end up with a local patch where I add the following to JMSModelDescriber::supports():

if (($model->getOptions()['useJms'] ?? null) === false) {
	return false;
}

As well as setting options: ['useJms' => false] in SymfonyMapRequestPayloadDescriber and SymfonyMapQueryStringDescriber where it instantiates Model. Those, IMO can never use JMS serializer anyway?

That "fixes" Swagger docs for those Symfony attributes as well as allowing me to opt-out of JMS Serializer usage for specific responses via e.g.

#[OA\Response(response: Response::HTTP_OK, description: 'OK', content: new Model(type: MyModel::class, groups: ['read'], options: ['useJms' => false]))]

Not sure if that's a good approach or not, it feels not that invasive and should help us move forward while keeping BC.

I could contribute this here too of course if a there is a need for it.

also just realized that this is close to what was suggested in #2056 (comment) :) maybe I can "upstream" it like that

Thanks @herndlm for your work on that PR.

Are you open to share your reasons for switching from JMS to Symfony?
I have the same setup: FOSRestBundle with JMS Serializer.

While goetas is doing a great job with both bundles, maintenance is pretty low and I am a bit afraid of the future for both bundles. So your PR peaked my interest and I wonder if you could share some thoughts about your move away from JMS.