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 80
Connected to
Escape character is '^]'.

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

                    "Much more than just kernels"


> > 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 
> 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 
> 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

Mark Baker.   Ottawa, Ontario, CANADA.

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