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. 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 <mailto: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 >
Received on Friday, 22 May 2015 18:11:31 UTC