> This API is not intended for UI usage, so why not do this? There are HTTP clients that are incapable of sending a request body with a GET request, because th

> This API is not intended for UI usage, so why not do this? There are HTTP clients that are incapable of sending a request body with a GET request, because the original HTTP/1.1 RFC [1] says that a client must not send a request body in a GET request. This has changed with newer RFCs, but 2616-compliant clients still exist. If you're going to do this, you need to support POST as well, to accommodate those clients. Indeed, ElasticSearch accepts both methods. At that point perhaps you might consider whether it's worth doing just to have a conceptually clearer HTTP method. My take on TFA as it pertains to this issue would be: why bother with the strict adherence to perceived REST principles here? The search API endpoint is not a resource that you're requesting that is identified by that URL; it's an operation you're performing, so why not just treat it like the RPC that it really is? [1] https://datatracker.ietf.org/doc/html/rfc2616 https://datatracker.ietf.org/doc/html/rfc2616 [2] "A message-body MUST NOT be included in a request if the specification of the request method (section 5.1.1) does not allow sending an entity-body in requests"