[FEATURE] Make all response structs their own type

[Jakob3xD]

Is your feature request related to a problem?

For example the SnapshotGetResp struct has a field named Snapshots which is an array of struct.
I want to write a functions that uses this struct, but it can't be used as it is not its own type.
So it can't be referenced in the function arguments.
https://github.com/opensearch-project/opensearch-go/blob/main/opensearchapi/api_snapshot-get.go#L43

What solution would you like?

All structs inside Resp types should become their own type.

What alternatives have you considered?

Otherwise I need to redefine the struct on my end instead of using the lib.

Do you have any additional context?

resp, _ := client.Snapshot.Get(ctx, opensearchapi.SnapshotGetReq{xyz})
for _, snapshot := range resp.Snapshots {
    err := someFunction(snapshot)
    if err != nil {
        return err
    }
}

func someFunction(???) error {
    return nil
}

[Caladrel65]

I'm running into this when trying to create mocked unit tests. I end up needing to define the inline struct of a SearchResp (which leads to defining the "total" field twice) every time I try to instantiate the SearchResp. Everything below is before I put any meaningful data into the response.

expectedSearchOutput: &opensearchapi.SearchResp{
	Hits: struct {
		Total struct {
			Value int `json:"value"`
			Relation string `json:"relation"`
		} `json:"total"`
		MaxScore float32 `json:"max_score"`
		Hits []opensearchapi.SearchHit `json:"hits"`
	}{
		Total: struct {
			Value    int    `json:"value"`
			Relation string `json:"relation"`
		}{
			Value:    0,
			Relation: "",
		},
		MaxScore: 0.0,
		Hits:     nil,
	},
},

[dblock]

I am secretly hoping someone do this as part of picking up #284 :)

[rootxrishabh]

Hi @dblock @Jakob3xD, I would like to help with this. I see GetSnapshot struct has been segregated already. Is this issue still open for contribution?

[dblock]

Is this issue still open for contribution?

Every open issue is open for contribution.

[sean-]

Resolved in v5preview/opensearchapi/; all generated types are top-level.

Thanks for filing this and for the concrete example - it described exactly the testability pain point. The regenerated v5preview/opensearchapi/ package (see #804) produces every nested response shape as a top-level struct, so SearchHit, SearchHitsMetadata, SnapshotInfo etc. are all directly referenceable in function signatures and test fixtures.

Closing as fulfilled in v5preview; v5 promotes those types to opensearchapi/ per #835. If a specific nested struct is still inlined in v5preview, please open a fresh issue pointing at it.