W3C home > Mailing lists > Public > uri@w3.org > November 2008

Re: [rest-discuss] RE: [whatwg] Proposing URI Templates for WebForms 2.0

From: Erik Wilde <dret@berkeley.edu>
Date: Sat, 01 Nov 2008 11:38:02 -0700
Message-ID: <490CA20A.7090901@berkeley.edu>
To: Subbu Allamaraju <subbu@subbu.org>
CC: Mike Schinkel <mikeschinkel@gmail.com>, "'Mark Nottingham'" <mnot@mnot.net>, "'Ian Hickson'" <ian@hixie.ch>, "'Jerome Louvel'" <contact@noelios.com>, whatwg@lists.whatwg.org, uri@w3.org, rest-discuss@yahoogroups.com

Subbu Allamaraju wrote:
> On Nov 1, 2008, at 10:01 AM, Erik Wilde wrote:
>> Subbu Allamaraju wrote:
>>> I see the use cases, but what is the server gaining with this 
>>> flexibility? In other words, how many servers out there are going to 
>>> benefit from this technique?
>> the question is more how many page authors will be able to reliably 
>> develop forms against services/servers? i think mike's idea is pretty 
>> good because it increases loose coupling between clients and servers.
> I don't disagree, and I do see the value of templates for non-browser 
> scenarios. But the most of the web today won't be taking advantage of 
> this for a long time.

that is certainly true. but i think there are cases where this already 
would be useful on today's web. if you consider services exposing 
information through GData, for example, then mike's proposal would make 
it possible to simply write a web form for these services. there already 
are quite a number of GData services out there, but i agree that for a 
long time to come, dedicated form-processing services will remain the norm.

>> on today's web, forms and services are more or less tightly coupled, 
>> and they almost are developed as one thing. mike proposes an 
>> architecture that introduces a more loose coupling, because a form is 
>> able to interact with more services than before.
> Again, I don't disagree about loose-coupling, but the technique serves 
> just a tiny tiny fraction. Also consider the amount of JS code out there 
> that knows how to construct URIs from form params and other inputs. That 
> won't be migrating to use templates anytime soon.

of course the installed base of code assuming that services are designed 
specifically for form-data processing is huge. and i do understand the 
hesitation to look beyond forms, because they are so popular and 
wide-spread. but really, RESTful services in non-form flavors are 
becoming more popular and more widespread, and i think it's safe to say 
that this is a long-term trend.

>>> Not having templates in forms does not violate URI opacity since HTML 
>>> forms do follow a well-defined and well-understood approach to 
>>> construct a URI from form parameters.
>> yes, but if you have some service out there that expect certain URIs, 
>> then currently it is not possible to build a form for that, unless the 
>> service does expect form-encoded data. mike's proposal would allow 
>> forms to interact with a much wider set of services.
> Same as above. Those services/servers can very well allow form-encoded 
> data. I would argue that, doing so is better since it would let them 
> work with existing browsers and JS libraries.

that is a circular argument. and in many cases, if you are building a 
RESTful service primarily intended as an API, then URI design for it 
will look very different from form-encoded data.

i think the main question is whether HTML should look beyond services 
designed specifically for backing forms, or not. it certainly could 
without harming backwards-compatibility, and one could also argue that 
this would actually promote the design and implementation of services 
with more well-designed RESTful APIs than form-encoded data. seen this 
way, such a feature would be a pretty smart way of slowly improving the 
state of how services are provided on the web.


erik wilde   tel:+1-510-6432253 - fax:+1-510-6425814
        dret@berkeley.edu  -  http://dret.net/netdret
        UC Berkeley - School of Information (ISchool)
Received on Saturday, 1 November 2008 18:39:16 UTC

This archive was generated by hypermail 2.4.0 : Sunday, 10 October 2021 22:17:51 UTC