Re: Call for Adoption: SEARCH method

[Asbjørn Ulsberg <[e-mail]>]

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.

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.

-- 
Asbjørn Ulsberg           -=|=-        [e-mail]
«He's a loathsome offensive brute, yet I can't look away»