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? 2. SEARCH, as briefly defined in the proposal**, how is it sufficiently different from GETs? 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." ... > > 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 >> > > >
Received on Tuesday, 26 May 2015 23:55:18 UTC