Re: Proposed issue; Visibility of Web services

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.

But it's _not_ just the methods which are relevant to intermediaries, 
even on the REST view. The request URI and the response entities matter 
too. 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.

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

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.

Cheers,


Miles

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