6

It seems 5 years ago there was a proposal for a HTTP SEARCH request, but it does not appear to have been adopted and it not widely supported. Are there any factual documents or citations which shed light on the reasoning behind why SEARCH has not been adopted by working groups or standards organizations?

There is also the w3c 'QUERY' verb. Both seemed to try and address the issue of whether to use a "POST" or a "GET" for a search request. Which is an issue that our team is trying to battle with now and seems to be the subject of much debate all over SE and SO.

I'm curious to why something like this was never formally adopted? We wondered if its down to the fact that there is no 1 solution in regards to query params vs request body and it has to be a judgement call, but I still see no reason not to have a verb with a request body that assures the user of no changes...

Dan Wilson
  • 3,073
  • 1
  • 12
  • 16
chrispepper1989
  • 327
  • 2
  • 8
  • I have not heard of these before. The idea is interesting, but in my opinion, GET makes sense for a search request, unless there are sensitive items in the search query that you don't want in the URL parameters. – neilsimp1 Jan 16 '20 at 12:56
  • 1
    The problem comes when the search becomes more complex, not only can it get laborious to add as query string parameters but also you can start to hit uri limits. Imagine for example you wanted to search for a question in stack overflow but only ones that had been done by a certain group of users with a certain group of tags. Such lists can be unwieldy (or to long) in query string parameters. Which forces you to be semantically incorrect with a post :( – chrispepper1989 Jan 16 '20 at 13:01
  • `GET` is `SEARCH`. `POST` is whatever you want to use it for, including `SEARCH` if you're so inclined. We already spend too much time obsessing over these verbs to add another one. – Robert Harvey Jan 16 '20 at 15:16
  • GET can contain request body. So arguments based on URL encoding or length limits are pretty much irrelevant. Any tools that doesn't allow you to work with request body to GET request are not standards compliant, so discard them and get a better tool. – Lie Ryan Jan 17 '20 at 03:15
  • To a certain extent I'm not sure why we care to use different http verbs; their intent can easily be encoded in the requested url. I suspect we use them because they are there – Caius Jard Jan 19 '20 at 07:35
  • For me the nice thing about verbs is it offers semantic context and the fact there are multiple ways of skinning the cat when it comes to search means its done in various different ways. For my feeling "GET" means your request will make no changes, "POST" will (try to) make changes. SEARCH should be like a GET in this sense of not changing things. Yet people rarely expect a GET to have a request body so there is confusion there. I agree the only recourse is clear URL... – chrispepper1989 Jan 21 '20 at 11:04
  • Here is a memo published 9-Nov-2021 - the HTTP QUERY method. The Abstract: _"This specification defines the HTTP QUERY request method as a means of making a safe, idempotent request that contains content"_. See https://www.ietf.org/archive/id/draft-ietf-httpbis-safe-method-w-body-02.html – prasad_ Jan 05 '22 at 06:17

1 Answers1

3

There doesn't appear to be broad support for an HTTP SEARCH verb, as evidenced by multiple drafts expiring without further action.

The example in the draft shows a SQL-like query in the request body, which is more like POST than GET. This would avoid issues with URL length limits or sensitive data in the query string.

A simple SPAQRL query with a Direct Response:

SEARCH /contacts HTTP/1.1 Host: example.org Content-Type: text/query Accept: text/csv

select surname, givenname, email limit 10

Microsoft also has some obsolete documentation on it related to WebDAV in which the request body is formatted as XML.

Another IETF draft was revived again in 2018 but expired last year.

Darrel Miller (of Microsoft) had this to say, and it might be the best you can find as far as "official" reasoning:

Unfortunately, SEARCH is so inextricably intertwined with WebDAV that it is really no use elsewhere. Unless of course you are going to pick and choose the bits of the spec versus the bits you don't but at that point, you might as well invent your own method called FIND or QUERY and write your own spec. At least then you will avoid the ambiguity.

OAI/OpenAPI-Specification #325 on GitHub

Community
  • 1
Dan Wilson
  • 3,073
  • 1
  • 12
  • 16