[Swashbuckle 5.1.4] Remove duplicated parameters

[PeterZong]

My API has 2 complex type parameters. They respectively have a property named AdditionalField. After the Swagger file generated, I can see 2 AdditionalField parameters. How can I remove the duplicated parameters?

My Code:
public User GetUserWithComplexParameters([FromUri] GetUserRequest getUserRequest, [FromUri] GetUserAdditionalRequest getUserAdditionalRequest)

Properties:
GetUserRequest.AdditionalField
GetUserAdditionalRequest.AdditionalField

[domaindrivendev]

If memory serves, WebApi will accept complex FromUri fields with and without the parameter name as a qualifier. For example, either of the following query strings would correctly bind the value to getUserRequest.AdditionalField

?AdditionalField=foo
?getUserRequest.AdditionalField=foo

When I implemented the workaround to handle FromUri parameters (this should really be done by the WebApi metadata layer - ApiExplorer), I made the decision to describe the parameters using the shorter version (i.e. non-qualified) because I thought that would be the more common use of FromUri.

However, your example now represents a use-case where this breaks down. I guess the code should be updated to qualify each query param with it's corresponding name in the method signature but that would probably be unexpected behavior depending on the way in which people are using FromUri.

I need to think about this a little more - in the meantime you would have to come up with some OperationFilter to qualify the parameters.

[PeterZong]

Yes, I agree that non-qualified version is more common. But since WebApi accept either of the query strings you mentioned above, almost inevitably there will be some people/teams would like to use the qualified version. Maybe new attribute is needed to indicate if use parameter name as the qualifier.

I believe OperationFilter can do anything and I'll try to come up with some OperationFilters for this issue. But it is better to provide an easier approach. :)

Thanks,
Peter

[domaindrivendev]

As per advice from @rynowak in the ticket referenced above, I think the right solution would be to have SB's implementation honor the FromUri.Name property. This way you can qualify the parameter names as follows:

public User GetUserWithComplexParameters(
    [FromUri(Name = "")] GetUserRequest getUserRequest,
    [FromUri(Name = "getUserAdditionalRequest")] GetUserAdditionalRequest getUserAdditionalRequest)

[PeterZong]

It looks good for me. Thanks.

[khalidabuhakmeh]

Hello, I have a similar issue but it comes from the fact that I want to use a one model in -> one model out approach.

here is an example.

[Route(/cars/{id})]
public IHttpActionResult Get(Input request) {
 // doesn't matter
}

public class Input {
  public int Id { get; set; }
}

What's happening, is I am getting two parameters: Querystring and Url part.

Is there anyone to give precedence to one over the other and tell swashbuckle to only ever have one?

[khalidabuhakmeh]

I ended up solving my own problem by using OperationFilters. You can see my code here at this blog post.

http://www.khalidabuhakmeh.com/fix-swashbuckle-and-swaggers-duplicate-parameters-issue-for-webapi

[domaindrivendev]

@khalidabuhakmeh - nice blog above. It got me thinking about the combined in/out model scenario.

IMO, The best way to handle this is to use "internal set" on the properties that can't be set by your consumer - makes sense semantically right?

This will cause the "readOnly" property to be set on the underlying Schema property and I believe the swagger-ui will honor this when describing the model as a body parameter.

Initially, I was thinking this simple change to your Id property would be sufficient. Then I realized that you're using ProductRequest as a query parameter (assume you're using FromUriAttribute) and the SB code that breaks this out into individual params DOES NOT honor the readOnly attribute - a bug!

It's a one line fix and I'll get it in Asap. After that, I believe you can achieve your goal by just adding a single word "internal" to your code.

[domaindrivendev]

@khalidabuhakmeh - just added the commit I was talking about - 52e5fad

Will be available with the next release

[domaindrivendev]

Should be resolved in latest release - 5.2.0