-
Notifications
You must be signed in to change notification settings - Fork 5.1k
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
[Azure Search] Resolve Swagger linter errors for management API #2242
[Azure Search] Resolve Swagger linter errors for management API #2242
Conversation
Support for PATCH was added to the Azure Search RP. This change adds it to the Swagger spec so it will be documented and included in generated SDK code.
It doesn't seem to be supported by the .NET ClientRuntime for resource-based polling.
"parameters": { | ||
"searchServiceName": "mysearchservice", | ||
"resourceGroupName": "rg1", | ||
"key": "Query key for browser-based clients", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Query key for browser-based clients [](start = 16, length = 35)
since this is an examples, should we put a fake key here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You found a bug in the example. Query keys are supposed to be deleted by value, not by name.
I'll use the same placeholder syntax here that I've used elsewhere. Looking at examples in other Swagger specs, I don't see any of the other Azure services using fake values. Some reasons I can think of for this include:
- Avoiding accidentally putting a real value in the examples.
- Avoiding triggering cred-scanning false positives.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Make sense. The two points is what I though you were trying to avoid by putting the description of what the value is supposed to be, using a placeholder is a better idea.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi There, I am the AutoRest Linter Azure bot. I am here to help. My task is to analyze the situation from the AutoRest linter perspective. Please review the below analysis result: File: AutoRest Linter Guidelines | AutoRest Linter Issues | Send feedback Thanks for your co-operation. |
@@ -969,17 +906,15 @@ | |||
"description": "Tags to help categorize the resource in the Azure portal." | |||
} | |||
}, | |||
"required": [ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why is "location" not required anymore?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same as above
@@ -819,29 +773,12 @@ | |||
} | |||
} | |||
}, | |||
"required": [ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I understand the reason to remove them as required - I could be wrong, but are you trying to allow "SearchService" to be an acceptable request payload for the "patch" operation? In that case, it might help to create some type like SearchServicePatchParameters
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right, I want the client programming model to be simpler by using the same type for both operations.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But that way "location" and "sku" are not validated in the create scenarios. @veronicagg Do you have any guidelines which is the recommended way?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
They are still validated by the RP. This is just a tradeoff between stronger type safety on the client versus fewer classes for the customer to deal with.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Discussed with Veronica offline - @brjohnstmsft Do you think you can add some descriptions to "sku" property so that users will know this is required in a create scenario?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure, I'll make that change.
Hi There, I am the AutoRest Linter Azure bot. I am here to help. My task is to analyze the situation from the AutoRest linter perspective. Please review the below analysis result: File: AutoRest Linter Guidelines | AutoRest Linter Issues | Send feedback Thanks for your co-operation. |
I recommend reviewing each commit separately.
This checklist is used to make sure that common issues in a pull request are addressed. This will expedite the process of getting your pull request merged and avoid extra work on your part to fix issues discovered during the review process.
PR information
api-version
in the path should match theapi-version
in the spec).Quality of Swagger