Add support for “multi” path parameters

[Rinzwind]

I have an API with tree resources, which are handled by a single handler method in the implementation. The URL template for these resources is something like: (in RFC 6570 syntax)

/tree.{format}/{name}{/nodeid*}

So /tree.json/foo points to a JSON representation of the root node of the tree named “foo”, /tree.json/foo/4/2 points to the second child node of the fourth child node of the root node and so on. There doesn't seem to be a convenient way to describe these resources as a single API GET operation in Swagger. The Swagger specification implies that the “allowMultiple” attribute can only be used for query parameters, not for path parameters.

[fehguy]

Hi @Rinzwind, Swagger wants you to declare what you're exposing, so you can certainly have a path like this:

/tree.json/foo/4/2

but you'll have to set the path like this:

/tree.{format}/foo/{first}/{second} and so on.

[Rinzwind]

Having to include all of these separate paths in the resource listing seems like a rather clumsy solution:

• /tree.{format}/{name}
• /tree.{format}/{name}/{nodeid1}
• /tree.{format}/{name}/{nodeid1}/{nodeid2}
• ...
• /tree.{format}/{name}/{nodeid1}/{nodeid2}/{nodeid3}/{nodeid4}/{nodeid5}/{nodeid6}/{nodeid7}
• ...

Furthermore, the maximum number of nodeid parameters isn't known beforehand. One does not need to do a similar expansion for “multi” query parameters either, it would be better to likewise support paths like /tree.{format}/{name}{/nodeid*} as well.

[fehguy]

So you're looking for the depth of the request to slice portions of the response JSON? Can you explain your primary use case for swagger? Code generation or UI?

[Rinzwind]

Our primary use case for Swagger is Swagger-UI. We don't use it for code generation, at least not yet. I'm afraid I'm not sure what you meant with your first question. It might help to say the idea behind making each tree node available as a separate resource (rather than just the whole tree as a single resource) is both because each node's data can be quite large, and to allow a DELETE operation on individual subtrees.

[perabello]

I have a similar problem and I think that swagger-ui not allow splash in the documentation structure. For path like "\company\tgss" for the service (example path for operation "company\tgss{idCompany}"), swagger-ui only shows "\tgss" on the header of operations. Swagger generates a correct json (with full path "\company\tgss"), but when it is showed in swagger-ui, the service path is cut.

Is this a bug or a swagger-ui specification?

[tarunsk2006]

I am new to this forum. We need this multi path parameter support in swagger-ui as we are using it to display and test api operations. Swagger being the API framework should support the API operations which can have multi path parameters but doesn't want API operation path to be defined for every possible path combination. For ex. as captured by Rinzwind /tree.{format}/{name} /tree.{format}/{name}/{nodeid1} /tree.{format}/{name}/{nodeid1}/{nodeid2}

Please advise if this bug is fixes in swagger editor 2.0 or later

[webron]

@tarunsingh18 - the spec just doesn't support it. As they say, it's not a bug, it's a feature.

[lucklove]

I have the same use case. @webron I don't think it's a feature. It's more likely a defect. It's not possible to describe tree resource with swagger.