Swashbuckle.webapi: Remove Model name from parameter when [FromUri] is used with Model

[tiwari-abhishek]

Hi all,
Is there a way to remove the model name from appearing before the method parameter name, when a Model is specified as a [FromUri] input parameter to a web API?

say I have a model called MyModel with 2 string properties Property1 and Property2.

if I have in my webAPI something similar to :
public async Task MyMethod([FromUri] MyModel model)
{
}

this appears as:
model.property1
model.property2

in the swagger UI.

and also when you try it, the querystring has model.property1="" and model.property2=""

is there a way to strip off the model name when a model is specified as an input parameter with a [FromUri] attribute?

[deluvas]

+1

Is it possible to remove the prefix with a filter?

[domaindrivendev]

Technically, Swashbuckle isn't wrong here. The requests it's generating should work. By default, FromUri supports the qualified parameter form (model.property1) and the unqualified version (property1).

So, really the question is do you want to prevent your API from accepting the qualified form? If so, be explicit about it and then the auto-generated docs will follow suit.

public async Task MyMethod([FromUri(Name = "")] MyModel model)

That's how SB rolls - it makes no assumptions about how you "want" to describe your API - code is truth!

[tiwari-abhishek]

Thanks I will try that out

[dgritsko]

We are having the same problem, and got around it using a custom implementation of an IOperationFilter that strips out the parameter name. We want it applied globally -- e.g., there are no cases in our API where we would actually want the prefix to be included in the generated Swagger. This seems like a relatively common use case -- perhaps this could be a configurable option for Swashbuckle?

[deluvas]

@dgritsko Thank you, I'll try that.
@domaindrivendev Thanks, SB is great so far.

[domaindrivendev]

The IOperationFilter approach is more convenient but IMO it glosses over the "real problem" which is that your API operation has two forms - one with fully qualified param names and one without. This is an implementation issue and is not really related to documentation. Although you expect consumers to be using the non-qualified form, you can't be sure and so you have to consider both cases when updating/versioning etc.