W3C home > Mailing lists > Public > public-webapi@w3.org > October 2006

Re: XMLHttpRequest: Why list HTTP method names

From: Maciej Stachowiak <mjs@apple.com>
Date: Tue, 17 Oct 2006 19:35:41 -0700
Message-Id: <A2E1AC9F-21C1-48C5-9A4F-EBB023F1F87E@apple.com>
Cc: Robin Berjon <robin.berjon@expway.fr>, Anne van Kesteren <annevk@opera.com>, "Web APIs WG (public)" <public-webapi@w3.org>
To: Mark Baker <distobj@acm.org>

On Oct 17, 2006, at 6:23 AM, Mark Baker wrote:

> On 10/16/06, Robin Berjon <robin.berjon@expway.fr> wrote:
>> On Oct 14, 2006, at 15:20, Anne van Kesteren wrote:
>> > On Fri, 13 Oct 2006 14:18:56 +0200, Robin Berjon
>> > <robin.berjon@expway.fr> wrote:
>> >> And you guarantee interoperability how?
>> >
>> > It's not the job of the XMLHttpRequest specification to guarantee
>> > interoperability on HTTP level features, imho. Anyway, as
>> > indicated, this is likely to be tested in the testsuite.
>> If you can't guarantee that at least a core set of methods will work,
>> the API is simply useless.
> I disagree.
> Common practice with HTTP is what declares what methods are in use at
> any given time.  As an API to HTTP - which provides portability, not
> interoperability -

I'm not sure what distinction you are trying to draw. HTTP definitely  
does provide interoperability - that is why it is a standards track  
IETF RFC. The IETF requires interoperable implementations of a  
specification for it to advance along the standards track. It even  
mandates a minimal set of methods that servers MUST support, GET and  

> XHR doesn't need to say anything about that.

A minimal set should definitely be stated, otherwise the API spec  
doesn't guarantee enough to do anything useful and code will  
inevitably depend on implementation conventions. An implementation  
that did not support, say, "GET" or "POST" but only did "HEAD" would  
be useless. It is simply a question of what the minimum set should  
be. I think GET, POST, PUT, DELETE and HEAD is a reasonable choice.

Received on Wednesday, 18 October 2006 02:36:08 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:16:22 UTC