Summing up on visibility(?)

On Wed, Jan 08, 2003 at 10:02:47AM -0500, Christopher B Ferris wrote:
> Again, if I have a POST that accepts entity bodies of type application/xml
> whose root element name is one of the following:
>         A) Feedback
>         B) Review
> and the body of the POST method happens to dispatch processing to 
> different
> handlers based upon which root element is carried in the entity body, are 
> you 
> suggesting that this is not a perfectly valid implementation strategy? 

Yes, insofar as it loses some of the benefits of REST as an alternate
solution exists.

But rather than get into that, let's try to go for some agreement.

Can we agree that visibility is reduced in this case described below?
That if an HTTP intermediary written by a third party in the transaction
were listening in, they would have more trouble following what was going
on?

PUT http://some-uri HTTP/1.1
Content-Type: application/x-you-dont-know
[blank line]
73a4oa736h47w346da87w36d478a6478a364876dw93784

If that ugly string were interpreted as a method, then that would
over-ride the meaning of PUT that the intermediary would be basing its
actions on (whatever they might be; caching, or whatever).  This
therefore makes it more difficult for the intermediary to follow what's
going on (i.e. less visible).

This is in contrast to if the ugly string was just opaque data on which
no further dispatch decision could be made.  Then the intermediary would
be able to conclude that the client was trying to set the state of the
identified resource to the value in that string, even if it didn't know
anything about the string or its meaning.

This is almost the same issue again, except that I'm not asking you to
agree that "less visibility = bad".  Any chance of even partial
agreement, that visibility is reduced in the slightest?

BTW, re GET, what can we agree on about its use?  I'd ask that you
take a stab at suggested text, since I don't really understand what
criteria you would use to determine when it was appropriate or not.

> You will argue that the POST should respond with a message that contains a 
> content-location
> header containing the URI of my stock tip. Well, fine. I could do that, 
> but I may have
> valid reasons why I might not, and I may not want that representation to 
> be cached or the URI 
> bookmarked. I have no way of authenticating you as having purchased the 
> tip, so I don't
> want to expose the material into public URI space lest it be compromised. 
> That would cost
> me lost revenue.

Hey, sure.  If you can't meet your requirements and conform to REST,
then that's fine.  But the Web is a Good Thing, so if you have to choose
between a solution that meets all your requirements without many of the
benefits of REST, and one that meets all your requirements *with* all
(or more of) the benefits, always go for the latter.

That's all I've ever asked for (I hope - it was certainly my intent).
FWIW, when Roy says "deliberately sucking", he means choosing the
former solution, when the latter solution is also available.

I think that answer pretty much sums up my response to the rest of that
part of your message.

>         http://192.168.1.20/current/mystocktip.html
> 
> How many nodes does the 192.168.1.2 IP address resolve to anyway? 
> Mwaaahahahahahaaa!

I can't find it right now, but TimBL wrote a note someplace about why
URIs shouldn't use IP addresses.  You could just as easily have
http://foo.bar.baz.ibm.com/current/mystocktip.html, and though it
would only resolve on the Intr*a*net, it would be clear it was an
IBM-minted URI if it got onto the Internet (and people on the Internet
could make assertions about it without any ambiguity).  See also;

http://lists.w3.org/Archives/Public/www-tag/2002Dec/0228

> > Absolutely, so long as there's no method in the SOAP envelope, or a new
> > HTTP-like protocol is developed on top of SOAP (i.e. where the methods
> > in the SOAP envelope mean the same as HTTP methods; GET, PUT, etc..,
> > i.e. they are uniform).
> 
> I'm sorry, and why can't we be using SOAP with another protocol, other 
> than
> HTTP? May I not use BEEP, SMTP, FTP, or WebsphereMQ? Assuming that I may,
> would it not be reasonable that I might want to expose the same set of 
> SOAP messages through all of these protocols? Sure, YOU consider that 
> tunneling
> and we've been down that road before. There is NOTHING in REST or RFC2616
> that constrains against tunnelled use of the HTTP protocol.

The uniform interface constrains against tunneling.  If you tunnel,
you're not reaping all of REST's benefits... unless you're tunneling
another protocol which exposes a uniform interface, I suppose.  8-)

And *please*, I was *not* suggesting you were stupid.  What I meant by
that statement was that this is a *monster* thread, and I'm sure
nobody's been keeping up with *everything*.  For those that are trying
to, well, with available time to spend on this a constant, and more
messages over which to spend that time, let's just say I don't blame
anyone for missing a point or two.  Heck, I skipped most of the "myth of
loose coupling" thread.

I know tempers can flare anytime somebody comes along with claims such
as mine. But please give me the benefit of the doubt that I have the
utmost respect for you and everyone else in this WG, just as I give you
the benefit of the doubt that you don't think similarly of me, despite
some of your colourful statements.  I assume that your reaction is due
solely to the seeming absurdity of some of my claims, as they no doubt
conflict with your current mental models of how all this stuff works.
They *are* lofty claims, I *completely* understand that.

Respectfully,

MB
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
Web architecture consulting, technical reports, evaluation & analysis

Received on Wednesday, 8 January 2003 14:22:37 UTC