Skip to content
This repository has been archived by the owner on May 3, 2018. It is now read-only.

URI template to REGEX URL #12

Open
graingert opened this issue Mar 27, 2014 · 8 comments
Open

URI template to REGEX URL #12

graingert opened this issue Mar 27, 2014 · 8 comments

Comments

@graingert
Copy link
Contributor

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
Copy link
Contributor

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

@mnot
Copy link
Member

mnot commented Jun 24, 2014

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
Copy link
Contributor

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" notifications@github.com 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
Copy link

Almad commented Jul 4, 2014

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
Copy link
Member

mnot commented Jul 9, 2014

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
Copy link

Almad commented Jul 10, 2014

@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
Copy link
Member

mnot commented Jul 11, 2014

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
Copy link

Almad commented Jul 11, 2014

OK, I'll try to lay it down.

graingert pushed a commit to graingert/uritemplate-py that referenced this issue Oct 13, 2015
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants