Re: Proposed HTTP SEARCH method update - QUERY is to GET what PATCH is to PUT

> On 27 Apr 2015, at 22:49, Julian Reschke <julian.reschke@gmx.de> wrote:
> 
> On 2015-04-27 22:34, henry.story@bblfish.net wrote:
>> ...
>> It is my feeling that the authors of this draf want to do the right thing here, but were worried
>> to come up with a new method name, and favored going with something existing like SEARCH rather
>> than try something new. I was hoping in the previous mail that SEARCH could be redefined to do
>> the right thing. But if it cannot then another method name is welcome.
>> ...
> 
> There are already three safe HTTP methods that take a request payload (PROPFIND, SEARCH and REPORT). Some software stacks already know about these (for instance, wrt whether a request can be safely repeated on network failure). There's simply no reason to create yet another one, when, from an HTTP point of view, it does exactly the same thing.

I think the disagreement is that SEARCH does what we need. To quote Roy Fielding's 
answer:

 " In both of those definitions, SEARCH was not a method that scoped its results 
   to the requested URI.  That URI, in fact, had almost nothing to do with the 
   results, making implementation of the method a significant security risk. "

I tried to argue that SEARCH could and should be seen as doing exactly that. If you 
have an argument that it does, by quoting the spec, then of course that would be great
as it would avoid another verb being created. I tried to defend SEARCH here

  https://lists.w3.org/Archives/Public/ietf-http-wg/2015AprJun/0244.html

by arguing that a resource can have information about another resource. I gave as
examples the Atom Syntax. In RDF I could do the same using the N3 notation to express 
something like this formally by using { } quotations, or without that by using rdfxml 
literals. For a human everyday example consider that above I quoted Roy Fielding's 
statement. You could now query this e-mail about what Roy Fielding wrote, but that 
would not be the same as having received and read the e-mail he sent. Hopefully the
two overlap closely but it is quite possible that he has changed his mind in the mean
time or that I quoted him out of context, and lost an important part of his 
argument. Still if you QUERY this e-mail with a standard query language, then I should
be able to do the same with my version of this e-mail and reach the same results.

IF you search for what Roy said, then you'd probably try to go to the archive to find
what he said there. 

So if SEARCH ( the HTTP verb used by WebDAV) could work by scoping its results to a 
resource R it could nevertheless still give results about other resources iff R 
made statements about other resources too. ( or perhaps at the limit if it contained them )
 
I gave an example for Atom xml. 

The reason it is important is that I SHOULD not get a certain result when querying R
directly and a completely different result when GETing R and then querying the 
representation.

Otherwise QUERY or SEARCH won't give me any efficiency advantage: all I'd have now are
two different results, and I'd need to make two requests for each resource: a GET and a 
SEARCH, and if I relied on one I might be coming to a conclusion different from what
someone using the other method would arrive at, which would lead to security issues.

That is why the results must be scoped to the result URI. Another way of putting it,
is that the only thing that matters about a SEARCH is the state of the resource and
the QUERY/SEARCH sent to it. 

If you accept that a resource can talk about another one, then the state of a resource
may be queried about what it believes the state of another resource is. It nevertheless
remains the state of that resource. If it is a reliable resource then of course you'd
hope that it makes correct statements about other resources. But that is just another
additional fact that need not come into the definition of QUERY/SEARCH.

I hope I have understood Roy correctly.  You know enough about WebDAV to tell me if
this is in the spirit of SEARCH, or if Roy is correct in stating that SEARCH was 
weakly defined. Note that it may have been weakly defined but that pragmatically all
implementations just do the right thing. It is just more work to proove that.

> 
>> For this I propose to use the verb QUERY, which I think would be much clearer and less heavy sounding than SEARCH, which is too active and open.
> 
> I don't see any difference between these, but maybe it's because English is not my mother language.

SEARCH is active. When I search for something it is usually because I have lost it, and so
I go round and round in circles, I call people, I try to remember where I went, ... I try to
bring as much external information to find what I am looking for. I may also look for something
that I am not quite sure I know about ( that's Meno's paradox ).

QUERY is much ligher. It is asking a question. You can search by asking questions, but questions are
primary. (If you don't have a question, do you know what you are searching for?) Querying is also one of those primary speech acts in philosophy of language. In a query a part of the sentence is missing, and you ask your interlocutor to find ways of filling it with information he has ( in his state of mind ) to make the sentence filled in true.

Q: Where is the cat?
A: On the mat.

=> The cat is on the mat.

Hope that helps,

	Henry

> 
>> ...
> 
> Best regards, Julian

Social Web Architect
http://bblfish.net/

Received on Monday, 27 April 2015 22:42:03 UTC