Re: PaceServiceError comments

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

Robert Sayre wrote:

> The safeness of GET is also a SHOULD, and dynamic resources with side 
> effects on GET are *explicitly* mentioned.

My thinking here would be - be completely explicit by using POST. 
There's less ambiguity.


> My point is that there is no correct status code to return from the 
> POST. The choice is not as obvious as ReST dogma would have it, but I'll 
> address that in a different thread.

Like I said; 204 is a good status code for POST. I don't understand 
why it's not (really).



> > Sure, but work with me here. You asked for a POST example - I gave it 
> > - now you're back to GET.
>
>
> Oh, you don't have to answer this one. :)

The answer is simple enough: GET is not the right method for 
reporting errors :)


> Can anyone give an example of a valid use case for the last paragraph of 
> Section 9.1.1?

I can give a use case (don't know about "valid" here). GET is used 
by Tomcat to reload|start|stop|deploy|remove a webapp. That's an 
example with side effects - I believe the argument is that it makes 
scripting simpler when you use GET.

Actual issues with using non-idempotent GET are caching or 
spidering. If you mandate GET, the second client that comes along in 
your example to report an error might not see 410 gone unless you 
add cache busting headers or a ? in the URI. If this is not an issue 
you should considering mentioning that. But if it is a issue or you 
find yourself wanting to spec pragma or some such, that's a sure 
sign POST is what you're after.

But as I've said - good Pace either way. I've said my bit and I'll 
follow consensus or your judgement re the method.

cheers
Bill