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.orgReceived on Tuesday, 4 November 2008 18:24:59 GMT
This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 4 November 2008 18:25:00 GMT