Re: Proposed HTTP SEARCH method update

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.

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.

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
>

Received on Wednesday, 20 May 2015 18:49:20 UTC