[FEATURE] Make raw JSON REST requests to OpenSearch

[dblock]

Is your feature request related to a problem?

Coming from opensearch-project/opensearch-clients#62, add support for making raw JSON requests.

What solution would you like?

Add a high level DSL, e.g. client.get and client.post.

[samuelorji]

@Xtansia , I'll like to pick this up. How do you suppose I go about this in a way that aligns with the long term vision of the project

[Xtansia]

@samuelorji I would say a first step is to investigate and document what's already possible in this style in the client, for example we currently accept arbitrary JSON for all the defined endpoints, so maybe try to understand how one of the existing operations works. Then you can share your findings here in the issue, and determine an appropriate design that is similar to the existing ones, but allows setting an arbitrary path and http method etc. It should still use a similar "transport" call that the existing ones use like https://github.com/opensearch-project/opensearch-rs/blob/94e7b724b957259f4268151fe2d08dd5d2a3eb25/opensearch/src/root/mod.rs#L4385C5-L4438C6

[russcam]

It's already possible to do this with the rust client with

use opensearch::OpenSearch;
use opensearch::http::headers::HeaderMap;
use opensearch::http::Method;

#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
    let client = OpenSearch::default();
    let body = b"{\"query\":{\"match_all\":{}}}";
    let response = client
        .send(
            Method::Post,
            "/_some_api_that_may_exist",
            HeaderMap::new(),
            None,
            Some(body.as_ref()),
            None
        )
        .await?;

    let string_response = response.text().await?;

    Ok(())
}

This can send a raw request to any endpoint, and you can use the *Parts enums to build a valid path to a known endpoint e.g. for search to a specific index

use opensearch::{OpenSearch, SearchParts};
use opensearch::http::headers::HeaderMap;
use opensearch::http::Method;

#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
    let client = OpenSearch::default();
    let body = b"{\"query\":{\"match_all\":{}}}";
    let response = client
        .send(
            Method::Post,
            SearchParts::Index(&["tweets"]).url().as_ref(),
            HeaderMap::new(),
            None,
            Some(body.as_ref()),
            None,
        )
        .await?;
    
    Ok(())
}

If you're wanting to support raw JSON strings for each concrete API builder that accepts JSON, the api_generator can be updated to introduce a new function, similar to body(...), that accepts a string slice and returns some API builder such as Search<'a, 'b, B>, where B implements Body trait (which String and &str do); the body(...) function accepts T where T implements serde's Serialize and returns Search<'a, 'b, JsonBody<T>>, so is intentionally constrained, but the underlying types support any Body.

[dblock]

The first example is what I'm after (no specialized classes like SearchParts), so documenting that would be a great start!

[samuelorji]

Will add this to the user guide

[dblock]

Closing via #196.

[Xtansia]

@dblock Shouldn't this stay open as we want a cleaner high-level wrapper as well?

[dblock]

I've been going back and forth. I think for this client it should be closed, client.send is perfectly fine for an interface, not sure we'd benefit much from a client.post or client.get, but reopen if you feel otherwise!