URI template to REGEX URL

[graingert]

In lots of python web frameworks, eg Django, all URI templates are specified with regex parameters

It would be great to steal this feature: http://hannesg.github.io/uri_template/doc/URITemplate/RFC6570.html#to_r-instance_method

So I can do things like url(uritemplate("download/{tag}/{+version}").as_re()), "myview", name="myname")

[deontologician]

@graingert, @mnot I took a stab at this, see comments in the PR

[mnot]

Not ignoring, just busy.

I'm hearing a fair bit of interest in defining a profile of uri templates (maybe a new level) that is able to be "reversed" -- i.e., given a URL and a template, you can pull the vars out of the URL.

Does that seem like the right approach?

[deontologician]

I like the idea. Is there any notion of what the syntax would be? Or would
it just specify semantics for reversing and resolving ambiguities etc?
On Jun 23, 2014 8:15 PM, "Mark Nottingham" [email protected] wrote:

Not ignoring, just busy.

I'm hearing a fair bit of interest in defining a profile of uri templates
(maybe a new level) that is able to be "reversed" -- i.e., given a URL and
a template, you can pull the vars out of the URL.

Does that seem like the right approach?

—
Reply to this email directly or view it on GitHub
#12 (comment)
.

[Almad]

I'd vote for "semantics for reversing and resolving ambiguities", just wanted to add another use-case.

I am working for Apiary; what people are doing here is that they specify a list of resources using URI Templates. It may look like this one (let's not argue about API design):

FORMAT: 1A

# Simple PHP-ish API

## GET /{path}

+ Response 200 (text/plain)

        Path response

## GET /{path}{?id}

+ Response 200 (text/plain)

        Path ID response

From this, we generate a simple "mock" server, that replies properly:

almad@arael:~$ curl --include http://uritemplatesshowcase.apiary-mock.com/abc
HTTP/1.1 200 OK
Content-Type: text/plain
Date: Fri, 04 Jul 2014 14:17:10 GMT
X-Apiary-Ratelimit-Limit: 120
X-Apiary-Ratelimit-Remaining: 119
X-Apiary-Transaction-Id: 53b6b766a467f40200007f22
Content-Length: 13
Connection: keep-alive

Path response

almad@arael:~$ curl --include http://uritemplatesshowcase.apiary-mock.com/abc?id=123
HTTP/1.1 200 OK
Content-Type: text/plain
Date: Fri, 04 Jul 2014 14:17:18 GMT
X-Apiary-Ratelimit-Limit: 120
X-Apiary-Ratelimit-Remaining: 118
X-Apiary-Transaction-Id: 53b6b76ea467f40200007f33
Content-Length: 16
Connection: keep-alive

Path ID response
almad@arael:~$ 

Therefore, our use-case isn't "is this URL matching that URI template", but "from this list of defined URI templates with possible multiple matches, which ones is matching this URL best?". Regexp is obviously not sufficient for that.

I think this is a non-unique use-case, as this is basically what every webserver/framework would be doing.

I am in the process of extracting our test-cases from our codebase, but I wanted to reach out for the interest and correct approach.

Basically, what we are doing (and it look like it's working in the wild) is "the template with most matching template segments is considered best". However, we have not supported some things (see the end of this article), but after re-reading the spec, I don't think they should change the algorithm above.

Our reference implementation is in JavaScript, but if this is considered the reference URI Template implementation, I don't think there are any problems with porting it over here.

What is the best approach here -- suggesting a PR to the test suite with test cases and then the implementation here?

[mnot]

I think a separate spec with its own test suite would be preferable; it would carve out the features that don't work well with this, and provide the algorithm for matching. Make sense?

[Almad]

@mnot It definitely does for matching; I think it will/should probably have a "level M" for URI templates as a side-effect.

Where should we start with the spec?

[mnot]

I like "level M" :)

Regarding the spec - if you want to start a wiki page on this repo, it should be easy to transform it into an Internet-Draft later...

[Almad]

OK, I'll try to lay it down.