Skip to content

Full support for level 4 URI templates #1583

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.

Sign up for GitHub

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

Jump to bottom
Closed
odrotbohm opened this issue Jul 14, 2021 · 0 comments
Closed

Full support for level 4 URI templates #1583

odrotbohm opened this issue Jul 14, 2021 · 0 comments
Assignees
@odrotbohm
Labels
in: core Core parts of the project type: enhancement
Milestone
1.4 M1

Comments

@odrotbohm
Copy link
Member

No description provided.

@odrotbohm odrotbohm added type: enhancement in: core Core parts of the project labels Jul 14, 2021
@odrotbohm odrotbohm added this to the 1.4 M1 milestone Jul 14, 2021
@odrotbohm odrotbohm self-assigned this Jul 14, 2021
odrotbohm added a commit that referenced this issue Jul 14, 2021
@odrotbohm
#1583 - Full support for level 4 URI templates.
8c48242 
Significant rewrite of UriTemplate to bring it up to level for template variables. We now additionally support:

* Composite values correctly
* Prefix values
* Multi-value template variables
* Path-style parameters
* Label expansion with dot-prefix
* Reserved expansion

Unit tests have been enriched with all examples given in the corresponding RFC [0]. Template variable types have been aligned with the terminology used in the RFC. Currently differently named types have been deprecated in favor of the new ones.

The commit slightly changes the behavior in two different aspects:

1. Query parameter values are now encoded as described in the RFC. Previously, special characters like comma (,) have not been percent encoded but now are. To create comma-separated values, expand an array of values instead of a prepared String. I.e. instead of expanding {?sort} with "foo,asc", expand it with [ "foo", "asc" ].

2. The aspect of variable optionality has been deprecated as it doesn't actually exist for template variables. This causes expansions that were previously rejected (e.g. ones using {foo} in paths) are now not rejected anymore. This is due to the way that the expansions are defined in the RFC.

[0] https://datatracker.ietf.org/doc/html/rfc6570
@odrotbohm odrotbohm mentioned this issue Jul 28, 2021
Closed
odrotbohm added a commit that referenced this issue Jul 28, 2021
@odrotbohm
#1485 - Ensure proper encoding for request parameter expansion.
99808ee 
We now use the encoding rules defined in RFC 6570 (URI templates, API introduced in #1583) to prepare request parameters added to the URIs rendered.
odrotbohm added a commit that referenced this issue Jul 28, 2021
@odrotbohm
#1485 - Ensure proper encoding for request parameter expansion.
db1cd5d 
We now use the encoding rules defined in RFC 6570 (URI templates, API introduced in #1583) to prepare request parameters added to the URIs rendered.
odrotbohm added a commit that referenced this issue Oct 28, 2021
@odrotbohm
#1696 - Re-instantiate conversion for request parameter template vari…
0712563 
…ables.

When adding a request parameter template variable and the URI part of the template already contains a request parameter we now automatically turn the variable type into request parameter continuation. That apparently got lost in the move to level 4 URI templates in #1583.
@odrotbohm odrotbohm mentioned this issue Nov 23, 2021
Closed
@mibollma mibollma mentioned this issue Dec 9, 2021
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@odrotbohm odrotbohm

Labels
in: core Core parts of the project type: enhancement
Projects
None yet
Milestone
1.4 M1
Development

No branches or pull requests
1 participant
@odrotbohm