Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

2020/06/27/exposing-custom-type-as-json-string-in-asp-net-core-api/ #44

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
utterances-bot opened this issue Oct 22, 2021 · 4 comments
Closed

Comments

@utterances-bot
Copy link

Exposing a custom type as a JSON string in an ASP.NET Core API - Thomas Levesque's .NET Blog

https://thomaslevesque.com/2020/06/27/exposing-custom-type-as-json-string-in-asp-net-core-api/

Copy link

Hi Thomas,

Thanks for the clear explanation.
The call to options.MapType only seems to work for responses though. Is there a way to also get the equivalent swagger description for parameters?
There's a stackoverflow question on this here, unfortunately without any answers:
https://stackoverflow.com/questions/52068622/swashbuckle-maptypetype-doesnt-work-with-parameters

Thanks,
Twan

Copy link

I'm guessing I need a TypeConverter...

@thomaslevesque
Copy link
Owner

Hi @AroglDarthu,

It works fine for me, parameters are correctly represented as string in swagger.
You do need a type converter for model binding to work, though.

Copy link

I found that if used on the query string, then both the model binder and swagger show a custom struct as if it were a complex type: ?date.year=0&date.month=0&date.day=0.

A corresponding IModelBinder can solve this for the api, but does not work for Swagger.
I would have thought that the options.MapType would be enough for Swashbuckle to correctly define the scheme in Swagger. Unfortunately for query string parameters it works a bit differently.

Adding a TypeConverter helps for both.

See also: dotnet/aspnetcore#4825

Repository owner locked and limited conversation to collaborators Aug 28, 2023
@thomaslevesque thomaslevesque converted this issue into discussion #59 Aug 28, 2023

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants