Evaluating HTTP Methods in the Spec

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