Question

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...

Was it helpful?

Solution

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

Licensed under: CC-BY-SA with attribution
scroll top