Re: REPORT method considered harmful

Roy T. Fielding wrote:
> I don't have any time to take this on, but at some point the TAG
> should consider an issue regarding the problems caused by the REPORT
> method and its harm to the Web architecture due to
>   a) replacing identification of important resources via URIs
>      with limited indirect access via a related resource:
>      <> section 3.6
>      [should have used a link to a version history resource].

RFC3253 indeed defines a separate version history resource, with its own 
URI (see 
<>); however 
that one is optional. Most servers I'm aware of indeed support VHR 
resources, thus clients do not need to use the version-tree report 
you're complaining about 

Please don't confuse characteristics of the REPORT method itself 
(<>) with 
specific reports it is being used for.

>   b) use as an ad-hoc query-language without consideration for caches:
>      <>
>      [should be using links to related resources].

Again, that's characteristics of a specific report. I agree with the 
analysis that this doesn't take caches into consideration, and I have 
complained about this on the CalDav mailing list. However, this has 
little to do with REPORT; would the authors have used GET or POST for 
batching, the problem would have been the same.

>   c) batching multiple independent requests through a single method:
> <>
>      [should be using a client implementation that supported pipelining].
> I would not be surprised to see SOAP messages carried via REPORT.

That would not be compliant to the RFC defining REPORT if execution of 
the message would affect the state of resources on the server.

> The method has no distinguishable semantics from POST aside from
> the ability to claim that it isn't just tunneling through POST.

Yes, it does:

 From <>:

"The REPORT method MUST NOT have changed the content or dead properties 
of any resource."

Best regards, Julian

Received on Thursday, 29 December 2005 08:52:35 UTC