Support optional path parameters with default value

[amarzavery]

As of today, Open API spec asserts that a path parameter should always be required. This is a good assertion.
However, we have some services in Azure that have optional path parameters with a default value. There has been an increasing number of requests from service teams to support this.

What do you think about the following assertion?

If the parameter is in "path", required field must be specified. If required is false, it must be supported with a default. Else, required filed should be true.

This provides more flexibility apart from taking care of the current assertion.

For example:

• "/kevault/{KeyType}"

{
  "name": "KeyType", 
  "in": "path", 
  "required": false,
  "default": "symmetric",
  "type": "string", 
  "description": "The type of key."           
}

Can this be included in the 3.0 version of the Open API Spec?

[webron]

Given the planned support for some other aspects of RFC6570, the requirement that path parameters are mandatory may drop altogether.

[amarzavery]

That would really awesome :)

[amarzavery]

Do you have a time range for when will the next version be public?

[webron]

Within a few months. The process itself is public so people can voice their opinions as we progress.

[fehguy]

Parent issue #574

[darrelmiller]

@amarzavery As noted on the original Autorest issue, 6570 optional path parameters wouldn't quite meet the needs of the original example.

[swettstein]

Given the planned support for some other aspects of RFC6570, the requirement that path parameters are mandatory may drop altogether.

and yet 3 1/2 years later, they still appear to be mandatory

[fehguy]

I think @webron used the word "may" because it's not for sure changing...

[swettstein]

i have seen lots of discussions about path parameters containing slashes but nothing on this issue regarding simple path parameters.

from what i've read so far, OAS is designed to be how one SHOULD describe an API, not meant to support how APIs have actually been implemented. if that is indeed accurate, then why SHOULD path parameters be mandatory?

[fehguy]

Quite simply, making path parameters optional changes the path semantics and can make resolution of the operation non-deterministic. I know we can all think of one-off use cases where one can justify why it makes sense that POST: /foo/{bar}/{baz}/{bat} may not overlap with POST: /foo/123 (bat was optional) but in the general case, it makes routing difficult to impossible.