Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add some sort of URI template API? #192

Closed
jimmywarting opened this issue Jan 2, 2017 · 6 comments
Closed

Add some sort of URI template API? #192

jimmywarting opened this issue Jan 2, 2017 · 6 comments
Labels
needs implementer interest Moving the issue forward requires implementers to express interest topic: api

Comments

@jimmywarting
Copy link

jimmywarting commented Jan 2, 2017

I'm working with service workers atm and I was looking for some restful url route parser and found this: https://github.com/geraintluff/uri-templates

I didn't know there was a RFC6570 spec until now.
It would be nice to have some kind of native standard API for this.

There are many URL route parsers and I thing it is very tedious to have so many to choose from. Not every route parser is the right tool for you since it depends on Node.js or Browsers History api. You need to take the time to find something and learn something new every time since every project have some other way of solving it.

alternative solutions
https://millermedeiros.github.io/crossroads.js/
https://github.com/snd/url-pattern
https://github.com/rcs/route-parser
https://github.com/troch/path-parser
https://github.com/cowboy/javascript-route-matcher
https://github.com/evaisse/meteor-route-parser

@annevk
Copy link
Member

annevk commented Jan 3, 2017

Couple thoughts:

  1. That RFC builds on top of RFC 3986 which the URL Standard is not entirely compatible with. So we can't use it directly.
  2. The rfc/route-parser library mentions that URI templates are too limited to solve the problem.
  3. It's not really clear to me what a good API would look like. We'd need some kind of concrete proposal and processing model, as well as implementer interest.

@annevk annevk added topic: api needs implementer interest Moving the issue forward requires implementers to express interest labels Jan 3, 2017
@jimmywarting
Copy link
Author

It's not very clear to me either what a good API would look like. Wasn't a big fan of wrapping things either like the URI template

"/date/{color}/{shape}/"
"/date/:color/:shape/" 

Would rather prefer the second option since i have been using Express.js a lot and i think it's also more readable.

fyi, i just went ahead and included the sw-toolbox that had route parsing included and are based on path-to-regexp

@annevk
Copy link
Member

annevk commented May 10, 2020

Note that #369 touches on this a tiny bit by defining how an external string would be encoded.

https://github.com/wanderview/service-worker-scope-pattern-matching is also of interest, but that's not really about URL construction, more about matching.

As for templating, seems it would be doable to build this on top of new URL() as URL.fromTemplate`https://example.com/date/${color}/${shape}/` and fromTemplate would take care of percent encoding per the rules we decide on in #369 (and perhaps we also ought to expose those separately). The challenge here would be if templating has to work beyond path/query/fragment as that would require quite a bit of special casing that might be trickier to do, but it's not clear to me that's needed.

@mnot
Copy link
Member

mnot commented May 10, 2020

URI template takes care of that for you - the context is in the template operators, so that e.g., a variable in a path can be escaped correctly.

The limitation that route-parser mentions is well understood; it wasn't a design goal to extract variables from a URL, and it doesn't sound like that's a goal here either.

I don't see why that spec being built "on top of" 3986 makes it any less usable for your use case...

@annevk
Copy link
Member

annevk commented May 10, 2020

Thanks, I misunderstood how https://tools.ietf.org/html/rfc6570 works. It does not use a parser to determine context. It seems you need to explicitly state context for the values and the result may therefore not be something that can be parsed as URL.

@annevk
Copy link
Member

annevk commented Oct 9, 2021

It seems that URLPattern takes care of this. I suggest we fold this into #635.

@annevk annevk closed this as completed Oct 20, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
needs implementer interest Moving the issue forward requires implementers to express interest topic: api
Development

No branches or pull requests

3 participants