Re: ERROR verb

[Bill de hÓra <bill@xxxxxxxxxx>]

Henry Story wrote:

> On 19 Jun 2004, at 17:16, Bill de hÓra wrote:
>
> > Henry Story wrote:
> >
> > > So let me make a first attempt at a rock solid case:
> >
> > > [...]
> >
> >
> > > Why this over a specialized solution with a URL for reporting 
> > > problems? This solution is the most conformant to the REST 
> > > architecture of the web. Not only can clients send ERR messages, 
> > > proxies could also do this, leading to a virtuous circle of compliance.
> >
> >
> > As I've said I don't believe this solution is RESTful. It relies on 
> > server sided magic and breaks at least two REST tenets - visibilty and 
> > uniformity, never mind a dubious programming technique!
>
>
> I guess I don't yet agree with you on this one.
> How can we resolve the question of whether it is RESTfull or not? REST 
> are some very general architectural principles...

REST is quite specific.

> How does sending an ERR differ from the HEAD query as far as restfulness 
> goes.

Ok, I'll try

HEAD semantics are specified in HTTP, any web-accessible resource 
will respond to it as specified; thus its uniform.

Note that this is not the same as saying; "X" is not in HTTP, but 
because it's not, any web accessible resource will respond to it 
uniformly, thus it's uniform. Oh and by the way, given what we know 
about web servers this is a neat trick to stuff diagnostics into 
their log files and whatnot - people can look there for issues 
around borked Atom over HTTP encodings.

The latter part is what I mean by programming with gotos/side 
effects or "magic". This is fragile imo.


> It is uniform: it works for all resources.

ERR does not work for all resources. If you claim that you can claim 
*any* unspecified method is uniform - which is certainly a clever 
play on words. But - it hasn't been even established it will work 
for all web servers. And really, when we cut to it, this is a method 
targetted at web servers not resources.


> It is visible: all the intermediaries can understand it.

No it is not visible - in fact its intended effect relies on it not 
being visible. It depends on side effects and implementation details 
of web servers. ERR is closer to cookies than HEAD in that respect.


> But it helps. 

It helps an *Atom* use case. There are perhaps other less intrusive 
and less fragile ways to help. I said earlier that this approach 
(new method) is one of last resort and I asked if we thought we are 
that point. Are we?


> Yes. We need a good document to help our discussion of RESTfulness . I 
> just read Fielding's Phd thesis, quickly I admit, but it does not strike 
> me that this is not RESTfull.

I've tried to explain that it is not RESTful above.


> > Would you consider an X- header pointing to an error resource instead 
> > of ERR?
>
> Would you put that in a GET request? We don't want to GET the resource 
> again. What if the resource we downloaded was just 100MB long?

(You mean representation) This is what HEAD is for.

cheers
Bill