-
Notifications
You must be signed in to change notification settings - Fork 679
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
GET requests that use complex objects #1038
Comments
domaindrivendev/Swashbuckle.AspNetCore#66 seems to reference that using the [FromUri] attribute on a property will work, but under .Net Web API 2 that attribute can only be applied to Class and Parameters as per https://msdn.microsoft.com/en-us/library/system.web.http.fromuriattribute(v=vs.118).aspx Maybe this is specific to .Net core? (yes, yes it is). |
For reference, the following IOperationFilter will perform this desired behavior - I'm hoping this isn't needed. Alternatively, it would be even better I suppose to point a $ref to the input request object being used (it's in the schema) but I didn't tackle this part.
|
I have the same issue: even though requests do work correctly with the extra I'm now using the snippet above, which works like a charm. |
@bobvandevijver Sorry but that link is not a spec document by any means I actually do prefer the extra |
The link contains the MS docs about what the code should do: so yes, it is not a spec in literal sense, but is does describe how it is supposed to work. When you have multiple objects in your controller parameters, the Conclusion: for single object arguments the |
@bobvandevijver I agree with you, for single object arguments the |
This is indeed more than just a styling issue. Query string serializers don't expect the extra |
@daniel-gwilt-software sounds like you should fill a bug report with NSwagStudio |
@heldersepu NSwagStudio does support creating C# from the JSON instead of the controllers, so this is what we'll use. It's really all the confusion created by not following the standard conventions that were upsetting. I believe that's what standards are for. To facilitate communication on intention. It also creates more work for developers to use tools that don't follow popular conventions. For example, I had to write a custom object to query string conversion function to hit the API instead of being able to use the built-in AngularJS and/or JQuery functions. (https://docs.angularjs.org/api/ng/service/$httpParamSerializer) |
@daniel-gwilt-software Who is not following the standard conventions ? |
@heldersepu It turns out support for Complex Objects in the query string are supported in the Swagger 3.0 spec, but Swashbuckle nor NSwag support 3.0 right now. Thanks for your help. |
Hi. I assume no updates on this perhaps? |
public void Apply(Operation operation, SchemaRegistry schemaRegistry, ApiDescription apiDescription) |
Hey all,
I can't seem to find a proper solution to dealing with GET requests that use a complex request object rather than individual method calls. Swashbuckle seems to do some flattening of the query parameters already but it prepends the variable name specified in the GET request. For some reason, it also generates a definition for the complex request object but doesn't use it - which leads to swagger warnings. I did find one other issue which seems to be referencing the same: #70 and domaindrivendev/Swashbuckle.AspNetCore#66 but I could not find anything in the 5.0 documentation that would lead me to believe this is already handled within Swashbuckle.
Example method:
When using:
instead of:
results in schema:
But really instead of "queryParameters.ids" it should be defining just "ids" as the parameter. Is there a way to do this without invoking a custom OperationFilter?
The text was updated successfully, but these errors were encountered: