W3C home > Mailing lists > Public > www-tag@w3.org > January 2003

Re: When to use HTTP

From: Mike Champion <mike.champion@softwareag-usa.com>
Date: Tue, 28 Jan 2003 19:38:54 -0500
To: www-tag@w3.org
Message-id: <oprjqj24odt3hq37@smtp.comcast.com>

Dan Connolly said:

> > [Mark Baker]
> > So I suggest that a position such as "if your app can *reasonably* be
> > made to look like that, use HTTP", would be superior from that
> > perspective.
> Yup.

Let me make sure I have this correct.  It sounds like you want the TAG to 
declare, as an authoritative part of the Webarch document, that it is best 
practice to use HTTP in any circumstance where an application can 
reasonably made to look like hypertext?  What body of practical experience 
in recasting Web services as hypertext applications would you point to in 
proposing this? What benefits would ensue to the application developer that 
would outweigh the costs of following such a recommendation, e.g. in giving 
up the one's current development tool (to the best of my knowledge, no 
shipping products support the Web method feature in SOAP 1.2), or the 
security/reliable delivery features of non-HTTP enterprise middleware 
products that are widely used in industry?

As much as I find the REST ideas a rich source of inspiration for hypertext 
AND web services developers, and as much potential as I think they have in 
providing *a* powerful design pattern for a variety of Web applications, it 
is premature at best to suggest that Best Practice in non-hypertext apps is 
the same as for hypertext apps.  I would very much like to see the TAG 
clarify its position on the principles that Mark Baker laid out as they 
apply to the hypertext Web, which is fairly well-understood at this point.  
I would not like to see the TAG or anyone else specify a priori theoretical 
constraints  in an area as rapidly evolving as Web services.

[speaking only for myself]
Received on Tuesday, 28 January 2003 19:39:52 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:55:57 UTC