I've upgraded to 1.1.0 and I noticed that [FromQuery] parameters now are required whereas previously they were optional. This is a problem for me because many endpoints have [FromQuery] parameters with default values so I don't want to have to give them values in the UI.
Are [FromQuery] params supposed to be changed from "required": false to "required": true in the most recent release, and if so, how can I manually set them to "required": false?
Thanks!
Sorry about this. It鈥檚 a breaking change and therefore should have been a major version jump. I just missed this case.
The change was actually addressing other issues for folks that want the to be required, so now I鈥檝e ended up in a wackamole situation. The whole required vs non-required scenario is confusing and needs better documentation and possibly more clarity through the code too.
In the meantime, you can make the parameters nullable to unset the required flag.
Hey, thanks for the quick response!
Yeh, I saw some of the older threads asking for the opposite, so I was guessing this might have been the case. It's not a huge deal since it just means we have to type in a few default values through the UI, because the API itself still works fine since we always give default values through code.
But yeh, we'll change the 'int' to 'int?'s if it becomes too annoying until (or if) there's any way to specifically set it to optional/required in the future.
You can mark this as closed if you want, since I mostly opened this to make sure I knew what was going on and to see if there was an existing way to set the properties to optional. Or keep it open for any future updates haha, up to you. Thanks!
Maybe adding an option for default nullable behavior? Like c.DescribeAllEnumsAsStrings(); .
I have similar issue on return model when int, bool, datetime become nullable in swagger. I have to add my own filter so that autorest can generate client models that match the server's.
@domaindrivendev I appreciate your predicament - can't please everyone. I suppose I'll throw my two cents here anyway. Many of my controller methods take query parameters for pagination. e.g.
public virtual Task<IActionResult> DoSomething([FromRoute] string id, [FromQuery] int perPage = 10, [FromQuery] int page = 1)
{
}
Now if I make them nullable, that means that users could actually set those parameters to null in their request (correct me if I'm wrong). That would mean I have to set the perPage and page variables to their defaults in the body to be safe, which undermines the point of default values in the method.
I suppose one solution would be I could write a filter or something similar to enforce correct values for pagination.
In the meantime, I'll probably just put up with swagger requiring values for these query parameters.
We have the same issue with pagination query params. Non-nullable params being required is a good default, but if there are default values in the code like GetItems(int page = 1) - such params should be optional.
Found an easy solution to fix default params based on operation filter for old Swashbuckle:
_(see the full version that supports complex type properties)_
public class UpdateOptionalParamatersWithDefaultValues : IOperationFilter
{
public void Apply(Operation operation, OperationFilterContext context)
{
if (operation.Parameters == null || !operation.Parameters.Any())
{
return;
}
var parameterValuePairs = context.ApiDescription.ActionDescriptor.Parameters
.OfType<ControllerParameterDescriptor>()
.Where(parameter => parameter.ParameterInfo.HasDefaultValue)
.ToDictionary(parameter => parameter.Name, parameter => parameter.ParameterInfo.DefaultValue);
foreach (var parameter in operation.Parameters)
{
if (parameterValuePairs.TryGetValue(parameter.Name, out var defaultValue))
{
parameter.Extensions.Add("default", defaultValue);
parameter.Required = false;
}
}
}
}
@whyleee You're a legend, thanks for that. I figured something like this could be done with operation filters. I modified slightly because some of my parameters with default values are enums, of which I use a string value.
In your larger example, I replaced this:
return parameterInfo.DefaultValue;
with this:
return parameter.Type.IsEnum ? parameterInfo.DefaultValue.ToString().ToLower() : parameterInfo.DefaultValue;
Thanks @twgraham 馃憤 I updated the full version with enums handling. It also takes MVC serializer settings into consideration whether to return numeric or string values, or string camel case values.
See #599
Most helpful comment
Found an easy solution to fix default params based on operation filter for old Swashbuckle:
_(see the full version that supports complex type properties)_