Align RESTful API verbs to read/write concerns to simplify RBAC

[dblock]

Is your feature request related to a problem? Please describe.

Coming from https://github.com/opensearch-project/opensearch-py/issues/95, a user attempted to set permissions on OpenSearch based on the GET vs. POST verbs, and found that some "read" operations, such as scroll, require POST. This is because scroll defines a "search context", such that the caller gets consistent results from for a period of time. While POST is the correct verb in this context, but semantically this is a read operation, and should probably not carry state.

Describe the solution you'd like Review semantics of read/write APIs and ensure that all read-only operations are GETs, all create operations are POSTs, all update operations are PUTs, and all destructive operations are DELETEs. Deprecate and subsequently remove everything else. This likely means disallowing POSTs for any kind of querying (and yes, a GET request is OK to carry a body).

[Bukhtawar]

@dblock I think GET with a body is considered as an ambiguous request and might lead to request smuggling.

A payload within a GET/HEAD request message has no defined semantics. https://tools.ietf.org/html/rfc7231#section-4.3

https://medium.com/@knownsec404team/protocol-layer-attack-http-request-smuggling-cc654535b6f 3.1 GET Request with CL != 0

AWS ALB can mark GET requests with body as ambiguous and based on the desync mitigation mode close connection

https://github.com/aws/http-desync-guardian/tree/main/docs

AWS ref : https://aws.amazon.com/about-aws/whats-new/2020/08/application-and-classic-load-balancers-adding-defense-in-depth-with-introduction-of-desync-mitigation-mode/

[SamStephens]

https://github.com/aws/aws-cdk/issues/17761 is possibly a better reference here. The AWS CDK is attempting to use HTTP Verbs to manage read/write access to Opensearch clusters.