I noticed you tried to fix DCO?

"Kim Pepper [[email protected]](mailto:[email protected])", but got "Kim Pepper [[email protected]](mailto:[email protected])".

Something is not adding up between your settings and the commit signature.

I noticed you tried to fix DCO?

"Kim Pepper [[email protected]](mailto:[email protected])", but got "Kim Pepper [[email protected]](mailto:[email protected])".

Something is not adding up between your settings and the commit signature.

I think I fixed that now? Let me know if it's still not rigt.

I've updated the ClientBuilder and refactored the endpoints callable into it's own factory class. I think this makes it easier to understand, and also allows clients to swap out an implementation or use a dependency injection container if they want.

I updated the client and namespace templates also. I regenerated afterwards and it looks like there are a lot of new API methods added. Should I use something other than https://github.com/opensearch-project/opensearch-api-specification/releases/download/main-latest/opensearch-openapi.yaml ?

I think setHandler are not working anymore right? So aws sig v4 needs to be adjusted?

I think setHandler are not working anymore right? So aws sig v4 needs to be adjusted?

Yes, I think we'd need to rewrite the guzzle middleware/handler without the ring dependency to make it easier for people who use AWS OpenSearch service to use signed requests.

Something is not adding up between your settings and the commit signature.

I think I fixed that now? Let me know if it's still not rigt.

Yep looks good.

I've updated the ClientBuilder and refactored the endpoints callable into it's own factory class. I think this makes it easier to understand, and also allows clients to swap out an implementation or use a dependency injection container if they want.

👍

I updated the client and namespace templates also. I regenerated afterwards and it looks like there are a lot of new API methods added. Should I use something other than https://github.com/opensearch-project/opensearch-api-specification/releases/download/main-latest/opensearch-openapi.yaml ?

Let's work on merging #223 separately from this not to mix in the PSR changes. It needs some attention to tests. If nobody picks it up here I can do it soon.

Fixed CI in #234. Will merge and make a release with #223 next.

Thinking about this more, returning HTTP Response might not be the best DX.

We should introduce a Response object that contains the body of the HTTP Response and any meta-data. We can add a toArray method to return the deserialized JSON. We can have 2 sub-classes ErrorResponse and OKResponse. The error response can have getErrorCode() and getErrorMessage() methods.

The Promise would also return this too.

Thoughts?

@kimpepper In other clients we return a strongly typed object that derives from a base class that also gives access to the underlying raw HTTP response from the network library "as is" along with some helper methods like status code or raw body. Note that OpenSearch returns more than JSON, too.

I fixed what was broken in #223 and merged, rebase.

@kimpepper In other clients we return a strongly typed object that derives from a base class that also gives access to the underlying raw HTTP response from the network library "as is" along with some helper methods like status code or raw body. Note that OpenSearch returns more than JSON, too.

I think the strongly typed object would require a lot of work on the generator side and might be out of scope for this issue?

Not sure whether it's worth a simple wrapper around the PSR Response and HTTP Promise that gets returned?

From my understanding the response content types can be one of:

• plain text
• json
• nd-json
• xml

but I couldn't find the docs to back that up.

I think the strongly typed object would require a lot of work on the generator side and might be out of scope for this issue?

100%

Not sure whether it's worth a simple wrapper around the PSR Response and HTTP Promise that gets returned?

I would if we think it makes it easier to extend it later in a common way across multiple transports (it feels like it would).

From my understanding the response content types can be one of:

• plain text
• json
• nd-json
• xml

but I couldn't find the docs to back that up.

We cover the range in https://github.com/opensearch-project/opensearch-api-specification, see https://github.com/opensearch-project/opensearch-api-specification/blob/07e329e8d01fd0576de6a0a3c35412fd5a9163db/tools/src/tester/MimeTypes.ts#L10.

OpenSearch returns plain text, JSON, nd-json, CBOR, SMILE, and YAML, most from cat APIs.

Did you see XML somewhere? That may be a miss in API specs :)

I created a separate PR #236 to deal with the bulk change to static return types.

Split out #237 for the endpoint factory changes here.

Thanks @kimpepper! Let's work through those.

Rebased on main and made a minor doc change.

@kimpepper WDYT about adding something like https://github.com/opensearch-project/opensearch-py/blob/main/UPGRADING.md?

Yep, I think that's a great idea.

Added UPGRADING.md

The UPGRADING seems to imply that we do have some backwards incompatible changes in returns and configuration? I that case I do think this should bump us to 3.0, right? The deprecations would say 4.0.

I added a lot of BC and deprecation triggers so this would go in 2.4.x and the BC layer removed in 3.0.x

Cool, cool. @stof and @shyim let's get this merged? Help review?

The only thing not mentioned is dropping async which wasn't working anyway.

The only thing not mentioned is dropping async which wasn't working anyway.

Add a line. Better safe than sorry.

Add a line. Better safe than sorry.

Added more details to the CHANGELOG.md

I've been doing some manual testing of the new API with the drupal/search_api_opensearch module to see how easy it is to use and so far so good.

I needed to create my own factories for Guzzle and Symfony as we allow Drupal config to manage a few of the settings such as base URI and basic auth.

Here's the issue https://www.drupal.org/project/search_api_opensearch/issues/3495196