Proposing adding SEARCH method

[paulhill]

We started using the SEARCH method when we found we couldn't gracefully accommodate our document store backed (reductive find) GET /users and our elastic-search backed (additive search) SEARCH /users.
It's a draft spec but seems pretty handy. We use it in anger at any rate.

[webron]

Hi @paulhill - do you have any online references to the SEARCH method? Even the draft spec?

[paulhill]

https://datatracker.ietf.org/doc/rfc5323/

We don't adhere strictly to that draft spec in that we only support a JSON body, but the basic principle is sound. It's like a simple GET request except the body is important because it contains search criteria. This allows us to cleanly separate the "GET with query params" reductive find (e.g. GET /users) from the relevance based (inverse document count) Google style additive search (e.g. SEARCH /users).
Mostly these days people will fall back to verbs in the URI to achieve this. e.g. findUsersByX or GET /users/search, but that ain't ReST, that's RPC and makes all the puppies cry.

[webron]

@paulhill - I'm inclined to add it. I admit I wasn't aware of it, and it does sound interesting.

I'm not going to merge it just yet as I want to modify the schema to support it too (currently working on that on a fork, lots of changes there).

Since you seem to be familiar with it quite a bit - are there any technical restrictions that should be imposed on SEARCH operations? I'm not talking about design considerations but actual technical restrictions that may affect a 'legal' operation as described by the RFC.

[webron]

@paulhill nudge ;)

[paulhill]

Hi, sorry, swamped.
No restrictions really. The spirit of the RFC seems to just be that a search query can be passed in the body, but the are no restrictions about how it is structured. It's structured just like a POST really but with the added implication of no side effects, like a GET.

[webron]

Sounds good. I'll add it soon then.

[fehguy]

👍

[webron]

I'm working on a new version on the 2.0_fixes branch. Would you like to resubmit your PR against that or should I just go ahead and make the modification myself?

[ePaul]

This pull request comes too late for 2.0 (that is out for more than a year), and for 3.0 it should be a diff to the 3.0.md instead. I guess this can be closed for now, as #325 is collecting a list of methods to support?

[webron]

Originally we considered adding it to 2.0 after release, but eventually didn't. As @ePaul mentioned, this can be closed now.