Optional path parameters

[fabi-o]

Hello,

like described here (swagger-api/swagger-ui#380), path parameters are required and can't be optional.

I use optional path parameters in a REST API for filtering, sorting etc.

Example:
www.example.com/users
www.example.com/users:filter=active
www.example.com/users:sort=name
www.example.com/users:filter=active:sort=name

Are there any plans to allow optional parameters in the swagger specifications?

[fehguy]

Hi, in the 2.0 spec, no we are not planning on supporting that. Does that syntax follow a framework or is that your custom design?

[fabi-o]

Ok thank you for that information. It's a custom design, not a framework.

[hekaldama]

@fabi-o, imho I recommend sticking with standards when designing your api. Is there anyway to change to params instead of path for those? If I was consuming your api, the use of :key=value would be confusing and I would much rather use ?key0=value&key1=value.

[fehguy]

closing as not supported in 2.0

[gwicke]

I'm the author of #935 above. In our API we have several paths that end in some optional path segments, and are using /path/with{/optional}{/segment} syntax to avoid duplication of almost-identical path objects. Modeling this as three separate paths would clutter both the spec & the UI with a lot of repetition.

There are quite a few libraries for RFC 6570 URL templates, so the implementation should not be much more work than picking one of those. Related API spec work like JSON schema hypermedia uses RFC 6570 as well. To me it seems that there are few downsides in adopting the full standard in Swagger 2.1.

[gwicke]

@webron, should this task be reopened so that it shows up in https://github.com/swagger-api/swagger-spec/labels/Swagger.Next%20Proposal?

[webron]

It does show up if you look at the opened and closed issues. Anything that's labeled Swagger.Next Proposal will be considered whether it's opened or closed. Once we finish the iteration for the next version, the issues would be relabeled as Swagger.Next Rejected, the version of the new spec or, if deferred, they'll keep the Swagger.Next Proposal label.

I'll reiterate over whether to keep issues as opened or closed and why once I finish my current work on the spec (should be done in a few days), but rest assured that anything that's labeled with Swagger.Next Proposal is open for discussion when we discuss the next version of the spec.

[tjwebb]

Hi, in the 2.0 spec, no we are not planning on supporting that.

There's no possibility for optional route parameters? How would I generate a spec for just about every express.js app which has routes like /foo/:bar?

[webron]

@tjwebb - you won't, at least not with the current version.