Conversation
…zure/azure-openapi-validator into bdefoy/suggest-scope-parameter
This rule should remain separate as it is a warning, not an error
bdefoy
requested review from
AkhilaIlla,
mikeharder,
rkmanda,
tejaswiMinnu and
weshaggard
as code owners
| ## How to fix | ||
|
|
||
| Remove all explicitly-scoped paths that only vary in scope and create a path with the `scope` parameter. | ||
|
|
There was a problem hiding this comment.
This may not be a good idea from a customer viewpoint as it makes it less obvious as to what scopes are truly supported. Before we decide one way or the other, lets first check how TypeSpec generates the different API paths for this scenario and align the linter rules to work with that.
There was a problem hiding this comment.
I don't see support in TypeSpec for the scope parameter, but I'm also not seeing how you can generate a spec with a resource at multiple scopes aside from extension resources. I might look into this a bit more and follow up
There was a problem hiding this comment.
I'm not sure that there is any use of a scope parameter outside of extension resources. I have not been able to find one in the private API specs repo yet, and I'm not sure how it would fit with the RPC.
There was a problem hiding this comment.
The scenario described in #750 is a rare case where an RP is attempting to basically duplicate endpoints. I will change the rule to look for duplicate endpoints like this.
3 participants
Add a rule that helps disambiguate paths that share the same
/providerssuffix by suggesting the use of thescopeparameter.