- From: Maciej Stachowiak <mjs@apple.com>
- Date: Tue, 17 Oct 2006 19:35:41 -0700
- To: Mark Baker <distobj@acm.org>
- Cc: Robin Berjon <robin.berjon@expway.fr>, Anne van Kesteren <annevk@opera.com>, "Web APIs WG (public)" <public-webapi@w3.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 HEAD. > 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. Regards, Maciej
Received on Wednesday, 18 October 2006 02:36:08 UTC