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

Subbu>> 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. 

HTML5 won't be taken advantage of for a very long time, so how is this a
critcism?

>> 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.

If URI Templates are added I can see them be immediately incorporated into
CMS like Drupal, WordPress and Joomla (I use the former two so I'll add it
if nobody else does) and frameworks like Ruby on Rails, Django, and CakePHP.
Most (all?) of those frameworks use clean URLs but can't use forms w/o using
Javascript and URI templates would be a cleaner and simplier approach that
it would be crazy for people NOT to use it. 

I for one will blog about it and promote if via Twitter and expect others
like dret and Jerome (and probably Mark) will do the same.

>> 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.

So your only argument against is someone would need to create a URI Template
library and then they would need to use it? Just how hard is it to find and
use another library? 

With that argument there should be no planning for HTML5 because "existing
libraries" don't work with HTML5, right?

@dret>> 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.

Well said.

-Mike Schinkel 
http://mikeschinkel.com


-----Original Message-----
From: Subbu Allamaraju [mailto:subbu@subbu.org] 
Sent: Saturday, November 01, 2008 1:56 PM
To: Erik Wilde
Cc: Mike Schinkel; 'Mark Nottingham'; 'Ian Hickson'; 'Jerome Louvel';
whatwg@lists.whatwg.org; uri@w3.org; rest-discuss@yahoogroups.com
Subject: Re: [rest-discuss] RE: [whatwg] Proposing URI Templates for
WebForms 2.0


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.

> 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.

> ( mike, please correct me if i am wrong. )
>
>> 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.

Sincerely,
Subbu
----
http://www.subbu.org

Received on Sunday, 2 November 2008 00:22:27 UTC