Re: NEW PREFERENCE - return=query-result

I agree past usage becomes a huge barrier. 

I think though that for those designing new protocols/apis on top of http, the model they can produce is arguably simpler without having to mix new channels and  re-appropriating content type to signal functionality etc.

I could go either way on an update only method. We already have put and patch. For that matter there is already lots of overlap between post and patch and it doesn't seem to be a problem. 

I also like the idea of service provider gateways/balancers being able to distinguish read vs write via the method as it can be used to enhance scale in some cases. E.g.,by routing read transactions to different servers. 

Phil

> On Sep 11, 2015, at 17:06, Matthew Kerwin <matthew@kerwin.net.au> wrote:
> 
> 
> On 12/09/2015 7:54 AM, "Phil Hunt" <phil.hunt@oracle.com> wrote:
> >
> > If you mean have multiple endpoints I agree. 
> >
> 
> Yep, that was what I meant.
> 
> [...]
> 
> >
> > "post creates a resource" becomes nice and consistent if we move reporting processing functions out of POST(things that do not change state) into a new method like SEARCH. 
> >
> 
> If we say "post modifies a resource" (including append, delete, etc.) then I half agree; but POST has been fuzzy for a long time, and no amount of decree from us will change people's behaviour. (I.e. many people using POST for SEARCH will continue to do so.)
> 
> If SEARCH is to be the unambiguous read-only-POST, you'd need an unambiguous writing-POST method too. That way things like response status codes could be clearly reasoned for each (especially things like 200, 303, maybe 404.)
> 
> That said, I have no problem with a fuzzy POST, be it mixing POST and SEARCH, or using a different POSTed-to endpoint for each action (including '?action=...' query parameters), or embedding action instructions in the POST body (SOAP anyone?).
> 
> The prefer(ence-applied) mechanism seems like a convenient fourth channel, but I'm with James that it's not the right use of 'prefer.'
> 
> Cheers

Received on Saturday, 12 September 2015 01:00:20 UTC