Open mikekistler opened 2 years ago
Discussed with @johanste in meeting, we target consistency to Rest vocabulary for Python (IOW, keep the lower case)
If no special logic is needed for these parameters, I think this issue is complete. I will close but please reopen if there is still some work needed for this.
Followup question here. We told the device update team to add 'x-ms-client-name' to the REST API definition to get the "proper" casing for orderby:
{
"name": "orderby",
"in": "query",
"required": false,
"type": "string",
"x-ms-client-name": "orderBy",
"description": "Orders the set of groups returned. You can order by groupId, device count, created date, subgroupsWithNewUpdatesAvailableCount, subgroupsWithUpdatesInProgressCount, or subgroupsOnLatestUpdateCount."
},
Will Python use the x-ms-client-name or the actual parameter name? If it uses the x-ms-client-name, then should we revert the change to REST API and require languages that want special casing to use transforms?
Python will generate this as order_by
, which I believe is what you're looking for
I don't think that is what I'm looking for. If there were no x-ms-client-name
annotation, then I think the Python generator would generate orderby
(with no underscore) and my understanding of Laurent's comment above is that that is what we want.
Reopening this issue. Seems like Python might want to special case this. Pulling in @johanste again to see if we want to always generate this as as orderby
The Azure REST API Guidelines recommend standard query parameters borrowed from OData. Some of these parameters have names that contain multiple words but are all lowercase run together, e.g. "orderby", "maxpagesize".
For client libraries, we want these names to be exposed as multi-word names using the appropriate language idiom, e.g. "orderBy" in .NET.
Our DPG generators (autorest-based or Cadl-based) should ensure the correct transformation of the parameter names in the REST API to idiomatic form for the target language.