I am thinking about how to implement a REST API endpoint for searching. As I see it, I have four options for how to implement search options, each with pros and cons:
- Use a GET endpoint with querystring params
- Use a GET endpoint with a payload (for example, a JSON payload)
- Use a POST endpoint with a payload
- Use a SEARCH endpoint with a payload
For completeness, here are the pros and cons I am thinking of:
- GET endpoint with querystring params
- Pro - Accurate verb, standards compliant
- Con - Limited option structure (key/values only), and URL size limit
- GET endpoint with a payload (for example, a JSON payload)
- Pro - Accurate verb, no size limit
- Con - HTTP specs say GET requests do not have meaningful payloads, and some frameworks may not support it (relevant question)
- POST endpoint with a payload
- Pro - Standards compliant, no size limit
- Con - Searching is idempotent, while POSTing is not. Basically, it's the wrong verb.
- SEARCH endpoint with a payload
- Pro - Accurate verb, no size limit
- Con - Is an obscure (non-standard?) HTTP verb
A lengthy, nuanced, and opinionated discussion could be had as to which of these is best, but that discussion is not the purpose of this question. Instead I ask: Is the SEARCH verb merely obscure and rarely used but still an official method, or is it non-standard?
I found this draft for the method, but not many more official documents about it. The draft echoed some of the points of the quadrilemma I posed above. It appears to me that the method is still merely a draft and can't be called "standard", though I am not overly familiar with how to read those documents.
Functionally, I guess my question is: Can I rely on self-touted standards compliant software to handle the SEARCH method? And if they don't handle it, can I appeal to their claim of standards compliance to force them into handling it? Boiled down even further, is it a reliable verb?
