damnhandy / Handy-URI-Templates

A Java URI Template processor implementing RFC6570

Home Page:https://damnhandy.github.io/Handy-URI-Templates/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Problems with partial expansion

osvaldopina opened this issue · comments

I think that partial expansion for form-style query parameter generates a wrong template if you does not provide the first variable. For example the following expansion:

UriTemplate.buildFromTemplate("{?param1,param2}").build().set("param2", "value").expandPartial()

generates the following template:

{?param1}&param2=value

And I thing it should be:

?param2=value{&param1}

I've gone back and fourth on this one, and I'm settling on the side of stating that this is correct behavior. The reason being that is that the original template explicitly stated that that variable group is part of a query string group. So it appears natural to start with

http://example.com/thing {?param1,param2}

and have it partially expand to:

http://example.com/thing{?param1}&param2=value

By changing it to

http://example.com/thing?param2=value{&param1}

It has now completely changed my original template as now it is using a continuation operator. The URI Template spec does not enforce ordering of any sort. If you look at the URI template test suite, you'll see that every implementation has to check for every possible ordering of the expanded variables. So maintaining order should not be considered here.

Before I close this, I'd be curious to understand what this might break or if this is matter of personal preference? Partial expansion is not part of the spec, so I'm open to it if the counter argument is sound.

I think you did a great job by changing from query to continuation on partially expansion. The partially expanded template maintains its ability to be further expanded. The problem arises because query parameters normally are not mandatory.
Consider the following template:
http://example.com{?param1,param2}
if you provide a value for param2 and it would expanded to:
http://example.com{?param1}&param2=value
Then the param1 template variable has to have a not null value in the further expansion or the final link would be:
http://example.com&param2=value
which is not a regular url.
By putting not expanded values at the end of the template assure that it remains expandable considering the non mandatory nature of query parameters.
I really think that the partial expansion is something very powerfull and usefull and it is not covered by the specification so in my opinion this variable order change does not break the specification and makes it easy to enrich the template in diferent processing steps.

Ah ha! Great point @osvaldopina, this is indeed a problem. Now I'm sold and I'll accept the pr.

This is now in the 2.1.2-SNAPSHOT