Re: Call for Adoption: SEARCH method

[Julian Reschke <[e-mail]>]

Am 27.11.2020 um 14:25 schrieb Asbjørn Ulsberg:
> tor. 19. nov. 2020 kl. 08:01 skrev James Fuller <[e-mail]>:
>
>> 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 ?).
>
> I agree. When I first brought this to the WG's attention, it was based
> on discussions around the use of GET with payload, which is both wrong
> and dangerous:
>
> https://github.com/elastic/elasticsearch/issues/16024
>
> In my view, SEARCH as currently specified only solves the first of
> five desirable properties of a new HTTP method:
>
> 1. Explicit support for a request payload.
> 2. Safe.
> 3. Idempotent.
> 4. Cacheable by default (keyed by payload).
> 5. Content-Type agnostic.

Hmmm?? It solves 1...3, unless I'm missing something.

5. Would be solved by this spec.

4. is non-trivial, and it would be good to solve that in general, not
just as a special case.

> Not attempting to solve any of the other properties is a missed
> opportunity, imho. I would support and implement the method
> regardless, but I would be much more in favor if we managed to give
> the method all of the five properties mentioned above.
>
> Wrt. cacheable by default, we may also consider a general HTTP header
> that can also be applied to POST, as suggested here:
>
> https://github.com/httpwg/http-extensions/issues/942
>
>> * does SEARCH naturally assume working on collection of resources (uri's) ?
>
> Not any more than GET with a query string?
>
>> * 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' ?
>
> The result of a SEARCH request should not impose any semantics on the
> response, imho. The semantics of the response is conveyed by its
> Content-Type, which the client can of course negotiate with the Accept
> header. Each item in the SEARCH result is not necessarily its own HTTP
> resource, although something like that would be possible with a multipart/*
> response Content-Type.

Yes.

Best regards, Julian