- From: Bob Aman <bob@sporkmonger.com>
- Date: Tue, 19 May 2009 12:35:01 -0400
- To: uri@w3.org
- Cc: Michael Burrows <asplake@googlemail.com>, joe@bitworking.org
> Ruby has excellent URI template support in the shape of Bob Aman's (sporkmonger's) addressable gem. Thanks. :-) > My conclusion therefore is to keep the more advanced features of URI Templates. The examples (if they're intended as a test set) could do with beefing up - I contributed a couple of bug fixes to Addressable that weren't covered by them. I did express regrets early on that URI templates didn't distinguish between optional and mandatory parameters, but I've dealt with that now in the surrounding metadata and it's no longer a concern. I'm with Michael here. Please keep the advanced features. Just because they only get used by a handful of people doesn't mean they're not useful. I suspect they're less used for a variety of reasons, through no fault of the URI template spec. Couple of factors: * They're obviously harder to handle than the {foo} case for anyone who's rolling their own URI template support. This will be less of an issue as library support improves. * Frameworks and application developers have been moving towards representing parameters like so: /{controller}/{action}/{id}/ Some people even have gotten the impression that "pretty" URIs are what REST is all about. There is a non-trivial number of people who think the presence of a query parameter is inherently unRESTful. With this kind of misunderstanding, it's not unreasonable to expect that the {foo} case will continue to be dominant in the real world for quite some time. * URI templates for routing are only just starting to catch on. I just submitted a [small patch][1] (which was accepted) to the Sinatra web framework that allows URI templates to be used for routing purposes. IMHO, the advanced features of URI templates are much more useful in this scenario. Well, aside from the neg and opt operators anyways. Right now my library throws an exception if you try to use them in a route because you can't extract a canonical value for the parameter. (Note that neg and opt are still useful for simplifying partial template expansion.) I've put a HUGE amount of work into the Addressable library, and if you haven't played with it yet and you're interested in my take on what URI templates can be used for, you may want to take it for a spin, even if you're not a Rubyist. > 1. Are there any real-world uses of the more complex URI Templates, or > is {foo} enough? I can say, unequivocally, yes. My current employer is making extensive use of them for an internal application. We have to maintain several UIs to our application, including a Flex one. We send URI templates to the Flex UI so that it knows how to get the right data out of our REST interfaces. Sometimes a template needs to get partially filled in before being passed to Flex, which was the motivation for the partial evaluation algorithm. (Essentially, Template + Mapping -> Template instead of Template + Mapping -> URI.) > 2. *If* the syntax is simplified to {foo} there is an opportunity to > support the parsing > case, ala http://bitworking.org/projects/1812/wsgidispatcher.html > Is that of interest to anyone? Yes, that's of interest, however, simplification is not really necessary to support this use case. See Addressable::Template.match. :-) I would be very interested, however, in seeing the reverse operation of each operator actually specified. Especially neg/opt, since it bothers me to have to throw those exceptions due to undefined behavior. I should probably note that a lot of the improvements I've made to Addressable are still only available via source control. So if you're going to take a look, you want to grab a copy off of [GitHub][2]. The test suite may also be of interest. It's rather extensive. Bob Aman [1]: https://sinatra.lighthouseapp.com/projects/9779-sinatra/tickets/217 [2]: http://github.com/sporkmonger/addressable/tree/master
Received on Tuesday, 19 May 2009 19:31:50 UTC