Skip to content

Support RFC 6570 optional path segments #935

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 2 commits into from
Closed

Support RFC 6570 optional path segments #935

wants to merge 2 commits into from

Conversation

gwicke
Copy link

@gwicke gwicke commented Feb 13, 2015

This adds support for the substitution of RFC 6570 optional path segments in
swagger-client. Example:

/some/path{/optional}{/path}

This patch is rather simple and limited. For example, it does not properly
handle order constraints. A better solution would be to use one of the
existing RFC 6570 libraries. One candidate for this would be
https://github.com/bramstein/url-template.

gwicke and others added 2 commits February 12, 2015 17:44
This adds support for the substitution of RFC 6570 optional path segments in
swagger-client. Example:

 /some/path{/optional}{/path}

This patch is rather simple and limited. For example, it does not properly
handle order constraints. A better solution would be to use one of the
existing RFC 6570 libraries. One candidate for this would be
https://github.com/bramstein/url-template.
Support RFC 6570 optional path segments
@webron
Copy link
Contributor

webron commented Feb 13, 2015

That's not supported by the spec so it cannot be supported by the UI.

@webron webron closed this Feb 13, 2015
@gwicke
Copy link
Author

gwicke commented Feb 13, 2015

@webron, I don't see an explicit mention either way in the spec. I did find a few inconclusive discussions on the subject (like this one), so went ahead & implemented it.

@webron
Copy link
Contributor

webron commented Feb 13, 2015

The spec explicitly says that path parameters are always mandatory, and as such cannot be optional.
Indeed, there have been talks about it and I expect it to be part of the next version of the spec.

I do appreciate the effort in taking the time to create this PR, however we can't incorporate it if it doesn't correspond to the spec.

@gwicke
Copy link
Author

gwicke commented Feb 13, 2015

@webron, thanks! Looking forward to 2.1 with URL template support.

@webron
Copy link
Contributor

webron commented Feb 13, 2015

Currently, there's OAI/OpenAPI-Specification#93. If you feel that doesn't cover enough, either add your input there or create a new issue with detailed information. That would help drive it forward. @maxlinc has good knowledge of it and together I'm sure we can come up with a stable solution for the next spec.

@gwicke
Copy link
Author

gwicke commented Feb 14, 2015

@webron, commented there.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants