7 comments

[ 3.8 ms ] story [ 24.9 ms ] thread
Um - shouldn't this have the [2012] tag for historical posts?

I mean, I love URI templates. They're neat, they're reversible, but they're not exactly new, right?

Hah, and in the week after I wrote parsers, renderers etc. for URI Templates... Anyway, they're cool, but I wish to <deity of choice> that they were actually reversible. They so nearly are, but they buggered it up with Level 4 modifiers. For example...

    /{lista:*,listb:*}
    +
    "lista": [ "one", "two" ], "listb": [ "three", "four" ]
    =
    /one,two,three,four
Now, reverse it. You can't because there's no way of knowing which elements belong in which list. It's so annoyingly close to being a pure dual, but it's not. So I've had to make up some irksome rules for the edge cases like that which make me sad, but make matching using templates feasible (wise? maybe not, see note in spec, but that note wouldn't be even needed if only... sigh). URI Templates are a good example of why I wish I worked on IETF specs, while also being glad I don't...
The tricky part of working on an IETF spec, though, is that a consensus is required. It's very possible that nobody thought of that idea, but it's also possible somebody did and it wasn't considered worth the complexity.

On another note, if you want it to be reversible, wouldn't you just slash-delimit the two lists?

They thought about it...

"Some URI Templates can be used in reverse for the purpose of variable matching: comparing the template to a fully formed URI in order to extract the variable parts from that URI and assign them to the named variables. Variable matching only works well if the template expressions are delimited by the beginning or end of the URI or by characters that cannot be part of the expansion, such as reserved characters surrounding a simple string expression. In general, regular expression languages are better suited for variable matching."

Oh yes, exactly! That was the note I was referring to obliquely. They're right, in a technical sense, but "wrong" (subjectively in some cases) when it comes to designing tools that work with URI Templates... It's absolutely a smart enough bunch of folks to get the tradeoffs, I just don't envy having to decide them. Even if, on this occasion, I may have argued more.

(Of course, a lot of standards, and this is one, are reflections, and unifications, of existing implicit standards. People had already started using some of these features, so they couldn't really drop them, and still see adoption. Not an easy balance!)

The level-4 modifiers are actually useful - I don't see their inclusion as a failure of a standard.

Ambiguity was going to be possible either way - here's a Level 2 example:

    /{+a}/{+b}
            ->  "/foo/bar/baz"
By "reversible" I meant it's possible to find something that reconstructs to the original URL (http://bit.ly/1H27rwD), much like you did.