Support advanced URI Template Syntax [SPR-10505]

[spring-projects-issues]

Oliver Drotbohm opened SPR-10505 and commented

There is an updated RFC for URI templates. Would b cool if we could either add features to current UriTemplate or come up with a dedicated abstraction.

---

Affects: 3.2.2

Sub-tasks:

• 17535 Support RFC 6570 style URI template encoding

Issue Links:

• 18706 Support limited subset of RFC 6570 syntax including operators "", "?", "/", "#" ("is duplicated by")

• 17347 Provide option in RestTemplate to encode slash in URI variables

• 16028 spring:url tag does not correctly encode forward slash / in path variable. Should be calling encodePathSegment

• 16275 UriTemplate does not escape semicolons in path segments

1 votes, 9 watchers

[spring-projects-issues]

Rossen Stoyanchev commented

UriTemplate actually delegates to UriComponentsBuilder but I see what you mean. Quite a few options in the spec but I guess we can build a mechanism and then support some or all of them.

[spring-projects-issues]

Brian Clozel commented

Did you have something in mind? The RFC describes 3 levels of possible implementations that we could target. Note: our current implementation has both expand/match capabilities; so we should consider upgrading both to the same level of implementation.

We could even use an existing test suite and the implementation details from the RFC!

[spring-projects-issues]

Oliver Drotbohm commented

The current UriTemplate only supports the simple string expansions, none of the other expansions work:

UriTemplate uriTemplate = new UriTemplate("/orders{?id}");
assertThat(uriTemplate.getVariableNames(), hasItem("id")); // fails - is "?id"

Even if you use the discovered variable names as is, the expansion doesn't work:

UriTemplate uriTemplate = new UriTemplate("/orders{?id}");
String variableName = uriTemplate.getVariableNames().get(0);
Map<String, String> parameters = Collections.singletonMap(variableName, "47"); // fails - is "/orders%7B?id%7D"

assertThat(uriTemplate.expand(parameters).toString(), is("/orders?id=47"));

[spring-projects-issues]

Rossen Stoyanchev commented

I guess we'll know more once we try it. Once we add support for operators it may be just as easy to support all operators. On a quick glance levels 2 and 3 at least look pretty useful. /cc Arjen Poutsma

[spring-projects-issues]

Brian Clozel commented

Assigned to me for the prototyping phase. We'll figure things out after that.

[spring-projects-issues]

Oliver Drotbohm commented

We've added support for that in Spring HATEOAS, although in a very limited form.

[spring-projects-issues]

Brian Clozel commented

Reconsidering this for 4.2. We'll see if we can make this happen!

[spring-projects-issues]

Rossen Stoyanchev commented

Note that we already support the "/" operator in UrlTag (see #16028) and we'll probably do the same in UriComponentsBuilder (see #17347).

[spring-projects-issues]

Rossen Stoyanchev commented

After some further looking, a number of differences have emerged.

Spring's UriComponentsBuilder parses a URI string into constituent components (host, port, path, etc) after which those components can be modified or completely replaced with builder-style methods. URI variables are then expanded into each component and encoding is applied against each (fully expanded) URI component, each according to its own URI syntax (i.e. whatever characters are allowed will not be encoded).

By contrast the RFC provides additional syntax for building up the URI through expressions. Accordingly the required parsing logic is different since the URL structure is not even apparent from the literal parts of the URI template (for example a {?var} will append a query string once expanded). It's two ways of achieving the same thing -- using builder-style methods to build up the URL or relying on variable expressions.

Also the RFC approach to encoding is quite different. In the RFC by default when URI variables are expanded all URI reserved characters are encoded. By contrast UriComponents applies encoding within each component one at at time and according to the syntax for that component.

We have yet to explore a final solution as well as to receive more votes and comments! It's clear however that it won't be a simple flag in the existing UriComponentsBuilder. Rather it will be a new RfcUriComponentsBuilder that may have some relationship to the existing UriComponentsBuilder, or it may not.

[spring-projects-issues]

Rossen Stoyanchev commented

Postponing since it's a bit late to achieve this for 4.2.

[spring-projects-issues]

Rossen Stoyanchev commented

Brian Clozel note that I've updated UriTemplateHandler and related classes (as part of #16275) inserting Javadoc that suggests the possibility to create a custom UriTemplateHandler that plugs in an alternative URI template library. I suggest we resolve this as Won't Fix for now.