Re: Proposed HTTP SEARCH method update

In line...

Phil

> On May 26, 2015, at 16:54, Wenbo Zhu <wenboz@google.com> wrote:
> 
> 
> 
>> On Fri, May 22, 2015 at 11:10 AM, Phil Hunt <phil.hunt@oracle.com> wrote:
>> It might be useful for someone to profile the HTTP SEARCH draft to show a use case that people can see the trade-offs.
>> 
>> That way we can see an example of some details.
>> 
>> I think SEARCH is sufficiently defined in line with the template established by the other HTTP methods. Over defining at this level can cause more problems than good. 
>> 
>> I have something in mind if people are interested.
> I think use cases would be useful. 
> 
> 
> Up to this point, the questions I would ask are:
> 1. Why can't the SEARCH method be extended to cover any read-only computation, e.g. a calculate service?

Not sure we want to turn this into an execute method. 
> 2. SEARCH, as briefly defined in the proposal**, how is it sufficiently different from GETs? 
GET reverts to its proper use of returning a single resource. 

We would be unloading get and making it a higher quality link. 

Filters on get end up creating more low-quality links to the same resource. 
> 3. The issue of URL length limit: is it a practical issue even under the exact semantics of a GET?
> 
> ** "The SEARCH method is used to initiate a server-side search." ... "The body of the request defines the query." ...

Bigger issue is exposure of sensitive information in URL which gets recorded in many logs where it should not appear. 
> 
> 
>  
>> 
>> Phil
>> 
>> @independentid
>> www.independentid.com
>> phil.hunt@oracle.com
>> 
>>> On May 22, 2015, at 10:41 AM, Wenbo Zhu <wenboz@google.com> wrote:
>>> 
>>> 
>>> 
>>> On Fri, May 22, 2015 at 12:26 AM, Julian Reschke <julian.reschke@greenbytes.de> wrote:
>>>>> On 2015-05-22 09:00, Wenbo Zhu wrote:
>>>>> ...
>>>>> Rather than seeing SEARCH as related to GET, maybe what we really need
>>>>> is just a safe/Idempotent POST (aka rpc). With reduced semantics the
>>>>> benefits of such a new method may become more obvious.
>>>>> ...
>>>> 
>>>> 
>>>> And that new method would be different from SEARCH exactly how?
>>> 
>>> Anything that does not apply to POST could be dropped, i.e. not limiting this method to search-like semantics (which is not well-defined or understood, and often overlaps with GETs). 
>>> 
>>> And the method name needs a separate discussion ... and maybe SEARCH is good enough (not because it's already implemented).
>>> 
>>>> 
>>>> Best regards, Julian
>