RE: No consensus on draft findings on Unsafe Methods (whenToUseGe t-7)

The discussion on this thread hinges on the intent and interpretation of the
two priniples in the draft at:

 - safe methods (GET/HEAD) should be used for safe operations: read, query,
view, ask, lookup 
 - safe methods must not be used for unsafe operations: write, update,
modify, tell, buy, agree 

The first of these can be read two way:
	a) when using GET/HEAD you should be doing something that is 'safe'.
   or b) the *only* methods you should be using for 'safe' operations are

So it would be good to get the intended emphasis straightened out.

It also seems evident that folks do use POST for some things that are
considered 'safe' and the there seems to be some acknowledgment that this is
not an unreasonable thing to do. 

So... it might be worth adding a clause to the effect that:

	"POST may be used for 'safe' operations" 

and detail the circumstances when this would be reasonable, those when it
would not and what is lost if in inappropriate choice is made.



> -----Original Message-----
> From: Larry Masinter []
> Sent: 22 April 2002 06:16
> To: 'Tim Bray'
> Cc:
> Subject: RE: No consensus on draft findings on Unsafe Methods
> (whenToUseGet-7)
> I'm still missing the place where "all safe operations should
> use GET" is justified as a piece of web architecture.
> I've seen what seems to me to be argument-by-assertion:
> ("it's part of the web architecture because  it's part of the web
> or argument-by-assumption:
> ("if we assume that all safe operations should use GET,
> then all safe operations should use GET").
> > It's precisely the job of the TAG to worry about web architecture,
> > especially when it appears that other WGs are blowing it off.
> The 'it' makes it sound like there _is_ a web
> architecture, and the job of the TAG is to describe it.
> But surely there's no intrinsic web architecture,
> there are a bunch of separately evolving bits and pieces:
> URIs, XML, HTTP, etc., all designed by committee.
> The job of the TAG is to propose architectural principles that
> are effective (they actually work, are implementable, can be
> supported) as well as leading (cause the right new work to
> happen.)
> "All safe operations should use GET" doesn't seem to fit
> within those constraints: while it sounds nice in principle,
> there are ample drawbacks to enforcing it, even for SOAP.
> Leadership is the skill of getting others to follow.
> Unimplementable findings aren't a good way to lead.
> Larry
> -- 

Received on Monday, 22 April 2002 06:10:17 UTC