W3C home > Mailing lists > Public > www-ws-arch@w3.org > February 2003

RE: Visibility (was Re: Introducing the Service Oriented Architec tural style, and it's constraints and properties.

From: Cutler, Roger (RogerCutler) <RogerCutler@chevrontexaco.com>
Date: Tue, 25 Feb 2003 11:36:47 -0600
Message-ID: <7FCB5A9F010AAE419A79A54B44F3718E01817D17@bocnte2k3.boc.chevrontexaco.net>
To: "Champion, Mike" <Mike.Champion@SoftwareAG-USA.com>, www-ws-arch@w3.org

OK, since you are appealing to me, I will cheerfully set myself up:

I think that putting just about anything in the URL's would be frowned
upon very seriously by the people concerned about security, at least
those that I am familiar with.  To heck with the identity of the user --
the nature of the service itself would probably be considered sensitive.
For example, if we send out 1000 HTTP messages to the same URL, with the
nature of the operation encrypted in the body of the message (BUY, SELL,
QUOTE PRICE, etc) I don't think there is much problem.  But if we send
250 to http://BUY and 300 to HTTP://SELL and so on, I think that in
itself would be considered unacceptable.  OK, so maybe if A is dealing
with X, then they previously agree that http://abra means BUY -- and for
B dealing with X they agree that http://cadabra means BUY -- maybe
that's OK in terms of security (I don't really know), but it sure
doesn't look very late bound or, in fact, very different from encrypting
the BUY in the message.  I pass on whether that approach would be

Our security people REALLY don't like putting stuff into URL's.  I think
that the level of interest in the REST style of implementing business
processes over the Web is practically nonexistent, at least in the
environments with which I am familiar.  There is similarly virtually no
interest in these debates, as far as I can tell, either.  

-----Original Message-----
From: Champion, Mike [mailto:Mike.Champion@SoftwareAG-USA.com] 
Sent: Tuesday, February 25, 2003 11:06 AM
To: www-ws-arch@w3.org
Subject: RE: Visibility (was Re: Introducing the Service Oriented
Architec tural style, and it's constraints and properties.

> I'm not sure about this part.  First off, how RESTful would
> it be to encode the identity of the user in the URI (unless 
> the resource IS the user, but I don't think that's what you 
> mean).  I'll appeal to Mark on this one.

I'll appeal to Roger, since he lives closer to the Real World than
either Mark or I do :-)  I was thinking specifically of the issue he
raised with respect to GET being frowned upon by many IT shops because
it was seen as potentially exposing confidiential information in
intermediaries, browser histories, etc.  Perhaps a thorough
understanding of REST principles wouldn't lead to this problem, but,
uhh, the sysadmins out there seem to barely understand the Web as it is,
much less the vision of the Web as it could be.
Received on Tuesday, 25 February 2003 12:38:23 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:41:03 UTC