Psr interfaces

[kimpepper]

Fixes #199

Description

This PR removes the dependency on a specific HTTP client implementation and introduces PSR-7, PSR-17 and PSR-18 interfaces.

Issues Resolved

It greatly simplifies the volume and complexity of the library codebase and removes the need to manage:

• client configuration: it can be now done directly on the implementing HTTP client, e.g. SSL, Basic Auth, Retries
• connection pools/host round-robin: this can be done with HTTP client middleware

Users of this library can choose from a number of synchronous and asynchronous HTTP clients including:

• Guzzle 7
• Symfony HTTP client

It greatly simplifies the volume and complexity of the library codebase. Specifically, it:

• removes a number of transient dependencies including ezimuel/ringphp which is not longer getting updates

Breaking changes

• We no longer json_decode the response body into an array.
• We leave that to the client to decide how they want to do that, e.g. deserialize into an object
• Clients can make use of \Psr\Http\Message\StreamInterface to decode the response in a memory efficient way

Tasks:

• Replace Guzzle specific code with PSR interfaces
• Remove unused code including Connection, ConnectionPool and CllientBuilder
• Ensure test coverage

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

[dblock]

I love this change, thank you! Let's iterate till we get this to green. I think it's a lot simpler than #228, what do you think @shyim?

• Sign DCO, git commit -s --amend for existing commits, force push.
• Add to CHANGELOG.
• Let's add an UPGRADING.md like https://github.com/opensearch-project/opensearch-py/blob/main/UPGRADING.md with details on migrating to this version.
• Should we keep a OpenSearch\ClientBuilder even with different parameters for easier migration?

[dblock]

I noticed you tried to fix DCO?

"Kim Pepper [kim@previousnext.com.au](mailto:kim@previousnext.com.au)", but got "Kim Pepper [kim@pepper.id.au](mailto:kim@pepper.id.au)".

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

[kimpepper]

I noticed you tried to fix DCO?

"Kim Pepper [kim@previousnext.com.au](mailto:kim@previousnext.com.au)", but got "Kim Pepper [kim@pepper.id.au](mailto:kim@pepper.id.au)".

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 ?

[shyim]

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

[kimpepper]

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.

[dblock]

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.

[dblock]

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

[kimpepper]

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?

[dblock]

@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.

[dblock]

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