Re: Proposed issue; Visibility of Web services

On Mon, May 26, 2003 at 08:46:06PM +0100, Miles Sabin wrote:
> 
> Mark Baker wrote,
> > No, it's mostly the shared understanding of methods which improves
> > visibility dramatically, not the headers.
> 
> OK, that's a clear and succinct statement of your position.

Thanks.

> But it's _not_ just the methods which are relevant to intermediaries, 
> even on the REST view.

Definitely.  Everything in a message contributes to the meaning of the
message in some manner.

I maintain that the method is pivotal, as it prescribes the agreement
about what can take place over the network.  Headers can modify that,
such as GET becoming "Conditional GET" with an If-* header.  But just
understanding If-* won't get you very far if you don't also understand
the method.

> The request URI and the response entities matter 
> too.

I assume you just mean that the response entity matters to the meaning
of the response message, not the request message.  It's true that HTTP
responses are not self-describing in this respect, but HTTP request
message are.

We probably agree.

> Even tho' an intermediary knows that a GET is a GET is a GET, it 
> can't distinguish the different semantic intent of,
> 
>   GET /foo HTTP/1.1
>   ...
> 
> and,
> 
>   GET /bar HTTP/1.1
>   ...
> 
> without knowing something about the role those URIs play in an overall 
> application. The most it can know is what RFC 2616 tells it: that those 
> individual GETs are safe and idempotent in the technical sense defined 
> in that spec.

Right.

> But there's a great deal more which might be relevant to an 
> intermediary. For instance a method which is "safe" in RFC 2616 terms 
> might be distinctly _unsafe_ as that's understood intuitively. For 
> instance, it might result in the transfer of confidential information 
> across an insecure channel.

Well sure, but !safe != unsafe as you have it there.  You're talking
about different kinds of safety.  Your "unsafe" property is not part of
the network interface, unlike RFC 2616's "safe".  It's something that a
developer needs to be aware of, but it need not be part of the network
interface, unlike 2616's notion of safety which is critical to enabling
a shared information space.

> More interestingly, the reponse could 
> contain URIs which the client application might proceed to POST to. In 
> the latter case, consider,
> 
>   GET /foo HTTP/1.1
>   ...                     HTTP/1.1 200 0K
>                           ...
>                           <uri>http://example.invalid/boom</uri>
> vs.,
> 
>   GET /bar HTTP/1.1
>   ...                     HTTP/1.1 200 0K
>                           ...
>                           <uri>http://example.invalid/phew</uri>
> 
> In the context of a use by a client application which will POST to a URI 
> returned in the response to a "safe" GET, the safety of the GETs of 
> /foo and /bar is coupled to the safety of subsequent POSTs to /boom and 
> /phew.

Not by 2616-safety, it isn't.  GET is safe, and POST isn't.

Like I said, what you describe is an important issue that developers
definitely need to be aware of, but IMO, it is not relevant to the
network interface.

> If we take REST seriously and use it to build hypertext-structured 
> distributed applications which are even slightly more sophisticated 
> that a simple standalone RPC we lose the trivial visibility that you're 
> using as a stick to beat RESTless Web Services with. If you _are_ 
> taking REST seriously you have to think in terms of visibility wrt the 
> whole, probably dynamic, hypertext graph defined by your applications 
> resources and the links between them, and you have to take into account 
> the actions of _all_ the various agents which traverse or support that 
> graph. Focussing on single requests in isolation and their effects on 
> servers is *not* enough.

In so far as I believe that the network interface need only concern
itself with 2616-safety, and not sensitive-info-the-URI-safety, I think
it is sufficient.

But I'd like to keep this discussion focused on visibility, if that's
ok.

MB
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
Web architecture consulting, technical reports, evaluation & analysis
  Actively seeking contract work or employment

Received on Monday, 26 May 2003 20:45:46 UTC