Re: Thoughts on TAG issue EndpointsRef47

[sorry if you see this twice - I sent it to -request unintentionally]

On Mon, Feb 07, 2005 at 12:27:18PM -0500, Christopher B Ferris wrote:
> I was simply pointing out that in terms of deployed software, the theory
> that you can use any old URI scheme in an HTTP request is not bourne out 
> in practice.

You don't see anything wrong with your test?

Here's something I just tried off the top of my head.  I suggest that
your hypothesis would be better tested with such an approach;

bork%  telnet www.kernel.org 80
Trying 204.152.189.116...
Connected to zeus-pub.kernel.org.
Escape character is '^]'.
GET ftp://ftp.kernel.org/pub/README HTTP/1.0

HTTP/1.1 200 OK
Date: Mon, 07 Feb 2005 18:01:11 GMT
Server: Apache/2.0.46 (Red Hat)
Last-Modified: Fri, 28 May 2004 14:42:23 GMT
ETag: "8004-71b-1d8851c0"
Accept-Ranges: bytes
Content-Length: 1819
Connection: close
Content-Type: text/plain

                            Welcome to the

                        LINUX KERNEL ARCHIVES
                            ftp.kernel.org

                    "Much more than just kernels"

           IF YOU'RE ACCESSING THIS SITE VIA A WEB BROWSER
                PLEASE USE THE HTTP URL BELOW INSTEAD!
[snip]

> > In the former case, clients have the same expectation (aka contract,
> > aka interface) as each other.  In the latter, they don't.
> 
> Say what? That makes no sense. In both cases, there is server-side 
> processing.

Right.  What does that have to do with the interface, which is what
provides the contract/expectation?

> Are you suggesting that in the first that the client need not be aware of 
> the
> nature of that processing whereas in the latter it does?

Not exactly.  What I'm saying is that in the former case, the client is
only aware of application-generic interface semantics, while in the
latter they're aware of application-specific interface semantics.

You seem to be focusing entirely the processing behaviour.  I don't
think such a focus will lead to any resolution of this disagreement,
because the processing is *identical* in both cases.  We're in complete
agreement on that.  The difference is entirely in the interface.

> > > For that matter, 
> > > what 
> > > is the "processing" mentioned in the first case?
> > 
> > It's whatever the service does, like processing invoices, orders,
> > notifications, etc..
> 
> And if the PurchaseOrder, Invoice, etc. carried an identifier (PO123, 
> INV123),
> that would be abuse of HTTP I suppose?

???  No, of course not.

> > > How is it different from 
> > > "an application-specific mutating operation" and exactly what is that? 
> 
> > 
> > An example of an application-specific mutator would be "orderShoes". The
> > difference is that POST is an application-generic mutator.  So, when
> > publishing my shoe ordering app on the Web/Internet, I don't expose the
> > "orderShoes" operation, I expose a URI to which the order document can 
> be
> > POSTed (a Facade).
> 
> But the only thing that the POST accepts is an <Order/>, so the reality is 
> that
> the POST is constrained beyond what is specified in the HTTP spec in 
> accordance
> with what the server has chosen for its processing.

No.  POST is POST.  That the server advertises that it only accepts
a particular media-type/schema/whatever doesn't change what POST
means, it only *extends* the aggregate semantics of the interface of
that service as a whole.

> How is this relevant to the issue of what is in the entity body of the 
> POST.
> MY point was that HTTP doesn't constrain this in any way. You have just 
> confirmed
> this point. Therefore, you can't make a case that WS-A voilates the Web 
> Arch
> if the HTTP protocol is the realization of the Web Arch we have today and 
> SOAP+WS-A
> is merely defining the content of the entity body of an HTTP POST (or GET 
> in the
> case of SOAP1.2 Response MEP/binding).

HTTP isn't a "realization of the Web architecture".  Only the
architecture of the Web itself is the Web architecture.  And when I look
at that architecture, what I observe is millions upon millions of HTTP
servers and intermediaries looking at the Request-URI value to determine
where the message is logically targetted.  WS-A, by not requiring that
the address of an EPR be encoded in the Request-URI when using HTTP, and
instead placing it elsewhere where none of those millions of blobs of
software knows to look for it, is therefore inconsistent with Web
architecture.

Mark.
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca

Received on Monday, 7 February 2005 19:37:30 UTC