Re: Proposed HTTP SEARCH method update

On Wed, May 20, 2015 at 11:48 AM, Phil Hunt <phil.hunt@oracle.com> wrote:

> Roy,
>
> Thanks for your comments.
>
> We seem to agree on the objectives to enhance the web, but come to a
> different conclusion. I’m not sure why yet.
>
> I’m observing GET with filters causing the same “damage” that you are
> suggesting search does.  I think it is worse because of the need to pass
> private or confidential information in URLs.  So my first need is to move
> away from overriding to somewhere else. Headers? Body?  Both have problems
> and can cause the client to make erroneous assumptions about the results.
>
> By the way, I found it interesting that people are having the same issue
> with DELETE on this thread. I’ve also started to run into issues around is
> delete really always a delete….this pushes the need for parameters on
> delete.  But I digress away from my use case.
>
DELETE with parameters as matching rules etc could really be just a POST,
the universal method for overriding with rpc semantics.





>
> In my use case, I would like to test a condition about an addressable
> resource rather than return it.  A matching capability is powerful because
> it exposes an “oracle” function that allows a client to ask a question that
> is true/false without needing the whole resource or even disclosing the raw
> information (e.g. an attribute). I’ve considered using match headers, but I
> worry about knowing the service provider got the headers intact. E.g. if
> the headers are stripped, the risk is too much information is exposed
> leading to bad assumptions (that a specific condition was true) on the part
> of the client.
>
> Over time, I think the use of SEARCH would reduce use of GET yes. But my
> thinking is it reduces the poor uses of GET. What it is really doing is
> purifying GET and unloading it from all this overburdening “function" stuff
> and making the quality of bookmarking and linking better.
>


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.





>
> Thanks,
>
> Phil
>
> @independentid
> www.independentid.com
> phil.hunt@oracle.com
>
> > On May 20, 2015, at 10:45 AM, Roy T. Fielding <fielding@gbiv.com> wrote:
> >
> >> On May 19, 2015, at 9:04 PM, Phil Hunt <phil.hunt@oracle.com> wrote:
> >>
> >> What I was trying to illustrate is that DELETE is also a function and
> it hasn’t turned the web into RPC.  Why have RPC methods like PATCH PUT and
> DELETE?
> >
> > They are not RPC methods.  They have uniform semantics, operate on the
> target resource,
> > and are defined in such a way that intermediaries can understand their
> intended effects.
> >
> >> I don’t see how SEARCH “hurts” the web. If GET is supposed to be a web
> linkable resource and not one with embedded RPC functions like SEARCH or
> for that matter delete (e.g. GET
> http://example.com/Users/123?method=delete). In a hypermedia web, don’t
> we want to keep GET from being overloaded with functions like search?
> >
> > SEARCH does not have uniform semantics (it means different things based
> on the body),
> > does not operate on the target resource, and is useless for
> intermediaries.
> > However, that isn't why it is bad for the Web.
> >
> > The reason SEARCH is bad for the Web is because it allows lazy fools to
> provide
> > reusable information in a form that doesn't have an associated resource
> identifier.
> > It provides the same function as a parametrized GET request without
> minting a URL.
> > In other words, it reduces the number of identifiable resources, which
> reduces
> > the network effect of linked resources, which harms the Web because it
> reduces the
> > power of the resulting information system.
> >
> > ....Roy
> >
>
>