Re: Call for Adoption: SEARCH method

On Thu, 19 Nov 2020 at 05:49, Julian Reschke <julian.reschke@gmx.de> wrote:
>
> Am 19.11.2020 um 04:39 schrieb James M Snell:

> > On Wed, Nov 18, 2020, 12:18 Philippe Mougin <pmougin@acm.org
> > <mailto:pmougin@acm.org>> wrote:

> > To be clear, this is not intended as a safe, idempotent equivalent to
> > POST. It is intended specifically to cover search/query operations which
> > are often ambiguously represented as GET or POST. I'm not quite sure
> > what a safe idempotent equivalent to POST would even be, but this is not
> > it.
> > ...
>
> FWIW, I disagree with that. Ignore the method name for a moment, and
> what's left is a retrieval operation similar to GET which additionally
> takes the request payload into account.

and I disagree with both of you ;) ... +1 for taking on the draft for
discussion.

it would help clarify what exactly s being proposed, as the potential
for developer
confusion is high (because we all know what SEARCH must mean, right ?).

Some of the answers of the following questions interest me for those
future discussions;

* does SEARCH naturally assume working on collection of resources (uri's) ?

* how to generically report errors on a single resource within
returned results (ex. does 207 multi-status apply ?)

* if we are not constraining result format (or content type eg. return
a text/uri-list) then what is different from a
GET with some meta data saying 'this is a search' ? There are a few
slippery slopes here and esp hard mapping
HTTP semantics over many different things generically (eg. file
systems, databases, higher order ex., SPARQL, etc etc etc)
w/o cgi-bin devolution.

The above further reinforces my unease of direct linkage to WEBDAV ...
but should be an interesting conversation.

James Fuller

Received on Thursday, 19 November 2020 06:58:29 UTC