Create/ Use a decoupled HTTP client

[Shelob9]

To make sure that changes to SaaS API and client plugin work toghether @zackkatz and I discussed the need for a PHP SDK/ API client for plugin to use, that can be installed via composer. This will make integrating in plugins or other php applications easier. Also, I will be able to test the API client against each change in SaaS app so we make sure it all works, and we can version the API and client together as needed.

This client should be decoupled from WordPress. It should inject an instance of Requests (used by WP core), which can be installed via composer and is available in WordPress -- its the low level API for WordPress HTTP API.

[inztinkt]

This client should be decoupled from WordPress. It should inject an instance of Requests (used by WP core), which can be installed via composer and is available in WordPress -- its the low level API for WordPress HTTP API.

Was looking into this and i seem to recall somebody from automattic/woo telling me that WP plugins should use wp_remote_request() so as to be compliant with some standards. I might be wrong or misunderstanding though. Let me know if that may be the case.

the need for a PHP SDK/ API client for plugin to use

I agree, for both SaaS and API vaults. This way the TL drop-in code has the WP functions and wrappers for interacting with the SaaS SDK + Vault SDK.

The big question is not if, but when.

It'd be amazing to have, it's more a matter of scheduling when is the right time to build it that way (as it could be seen as over-engineering the MVP/beta)

[zackkatz]

@inztinkt Yes, though wp_remote_request() is just a wrapper for the WP_Http class, which uses the Request class for its requests.

That's what @Shelob9 is suggesting: just use Request directly; the data being passed to it will be in the same format as wp_remote_request().