- From: Adam van den Hoven <adam.vandenhoven@gmail.com>
- Date: Tue, 18 Dec 2007 07:35:05 -0800
- To: "public-html@w3.org Tracking WG" <public-html@w3.org>
- Message-Id: <A2EA204E-3EC4-44DA-8237-A2E84BA54233@gmail.com>
Good morning, I've been thinking about this as I'm building an online banking application for the iPhone. I've often argued that HTML browsers are not RESTful clients since they are only capable of issuing GET and POST commands (at least from user initiated events). JavaScript and the XHR object is restful, but the browser itself is not. I've always thought that this was a failing of HTML; its resulted in some (necessarily) unfortunate design. Either you use a GET to delete something or you create a form that consists solely of a submit button. Either you have suspicious markup or you have ill-advised server code. I think that there are some very simple things that we can do to improve the state of things. 1) Allow a METHOD attribute on any element that allows an HREF or ACTION attribute (namely 'a' and 'form' tags) 2) Allow any HTTP method in the METHOD attribute, including those not defined by HTTP. (i.e. allow one to introduce new, ad hoc methods - which is allowed by the HTTP spec - without breaking HTML) There has been some discussion recently regarding whether or not to use a POST for the PING attribute. In this discussion, I recall that some people pointed out that people rely on visual cues (link vs. button) to identify whether a particular action will have a side- effect. I can suspect that similar objection may be raised to my first proposal. Whether or not users will comprehend the purpose of a particular component is a matter for the designers to worry about, not the the recommendation framers. Regardless of what we specify, good designers will ensure that the purpose of a feature is obvious and very bad people (VBP™) will go out of their way obscure what the true purpose is. I think that this is a relatively simple addition to HTML that won't break existing sites (assuming we define the defaults as they currently are) and will add a lot of utility, finally allowing developers to use the full range of the spec.
Received on Tuesday, 18 December 2007 16:29:38 UTC