- From: Subbu Allamaraju <subbu@subbu.org>
- Date: Tue, 4 Nov 2008 10:24:40 -0800
- To: Erik Wilde <dret@berkeley.edu>
- 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
On Nov 1, 2008, at 11:38 AM, Erik Wilde wrote: > 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. Not sure how you came to that conclusion, but I find that argument a stretch. If I understand correctly, Mike's argument for supporting templates is to avoid requiring JS support. So, a RESTful server that needs to be consumed by a browser without requiring JS support has just one option - that is to use a media type that can be recognized by browsers, which is HTML. That is, it uses (X)HTML representations, supports query parameters and forms. The so-called API server therefore becomes a web server. I can understand the merits of URI template support for HTML on its own, but I don't think it is correct to argue that such a support will make it easy to consume APIs. Sincerely, Subbu --- http://subbu.org
Received on Tuesday, 4 November 2008 18:24:59 UTC