add support for guzzle 6

[dwsupplee]

Notable changes:

• Organized classes under new namespaces (ex. Google\Auth\GCECredentials is now found under the Google\Auth\Credentials\GCECredentials namespace
• Renamed 'getFetcher' to 'getSubscriber'

use Google\Auth\ApplicationDefaultCredentials;

ApplicationDefaultCredentials::getFetcher() // no-mo
ApplicationDefaultCredentials::getSubscriber() // +1

• Added guzzle 6 middleware implementations

use Google\Auth\ApplicationDefaultCredentials;
use GuzzleHttp\Client;
use GuzzleHttp\HandlerStack;

$middleware = ApplicationDefaultCredentials::getMiddleware(
    'https://www.googleapis.com/auth/taskqueue'
);
$stack = HandlerStack::create();
$stack->push($middleware);

$client = new Client([
    'handler' => $stack,
    'base_uri' => 'https://www.googleapis.com/taskqueue/v1beta2/projects/',
    'auth' => 'google_auth' // authorize all requests
]);

$res = $client->get('myproject/taskqueues/myqueue');

• Support for guzzle 5/6 as the default transport layer - however you can now also define a custom layer as follows:

use Google\Auth\Credentials\GCECredentials;
use GuzzleHttp\Psr7\Response;
use Psr\Http\Message\RequestInterface;

$isOnGCE = GCECredentials::onGce(function (RequestInterface $request, $options = []) {
    // define your own http implementation which returns a PSR7 response
    return Response(200);
});

The code is functional but please keep in mind there are still a few @todos which need to be addressed.

[googlebot]

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed, please reply here (e.g. I signed it!) and we'll verify. Thanks.

---

• If you've already signed a CLA, it's possible we don't have your GitHub username or you're using a different email address. Check your existing CLA data and verify that your email is set on your git commits.
• If you signed the CLA as a corporation, please let us know the company's name.

[dwsupplee]

I signed it!

[googlebot]

CLAs look good, thanks!

[Nyholm]

@dwsupplee Have you seen #81?

[dwsupplee]

I have! HTTP Plug is pretty interesting, it is definitely something to keep an eye on as it evolves and gains traction with the community. Keep me posted! :)

[bshaffer]

@Nyholm I imagine since this is PSR-7 compatible and uses middlewares, PHP-HTTP will be able to play nicely?

[Nyholm]

This PR replicates half of the things I've done in #81.

@Nyholm I imagine since this is PSR-7 compatible and uses middlewares, PHP-HTTP will be able to play nicely?

Im not too sure you understand PHP-HTTP (sorry, "Httplug". PHP-HTTP is the organisation). We want our code to be PSR-7 because it's great and a community standard. That is something we should do and I'm sure that you agree.

Guzzle on the other hand, is also great but it is not a standard. (Though, it is popular) By using the power of PSR-7 we can remove the dependency from Guzzle. Which is good because you should not rely on a implementation, that's not SOLID.

So, we need an interface to rely on that Guzzle implements, say a PSR7RequestSenderInterface. That is Httplug.

[dwsupplee]

@Nyholm

Im not too sure you understand PHP-HTTP (sorry, "Httplug". PHP-HTTP is the organisation). We want our code to be PSR-7 because it's great and a community standard. That is something we should do and I'm sure that you agree.

I think we understand what HTTP Plug is trying to achieve - the issue is it seems we are not comfortable relying on the implementation at this point in time.

Guzzle on the other hand, is also great but it is not a standard. (Though, it is popular) By using the power of PSR-7 we can remove the dependency from Guzzle. Which is good because you should not rely on a implementation, that's not SOLID.

This code does adhere to PSR-7 and you are able to override the transport layer with whatever implementation you choose (including php-http's!):

use Google\Auth\Credentials\GCECredentials;
use Http\Adapter\Guzzle5HttpAdapter;
use Psr\Http\Message\RequestInterface;

$adapter = new Guzzle5HttpAdapter();

$isOnGCE = GCECredentials::onGce([$adapter, 'sendRequest']);

So, we need an interface to rely on that Guzzle implements, say a PSR7RequestSenderInterface. That is Httplug.

HttpPlug is one way of achieving this goal. I genuinely appreciate where you guys are coming from and am interested to see where it goes.

[bshaffer]

This is now merged, but because I rebased, it doesn't realize it's merged.

[sagikazarmark]

Hey guys, HTTPlug developer here.

Although I am not a fan of passing around callables, I have to admit it works and usually provides great flexibility (which is not always an advantage), like in the case above. I like the implementation, but to be completely fair, I would like to correct some things about our interface:

It is HTTPlug, not HTTP Plug. We played with the words a bit. 😄

the issue is it seems we are not comfortable relying on the implementation at this point in time.

HTTPlug is a set of interfaces, there is no implementation in it. We PROVIDE some implementations. I would be happy to hear some feedback: are there any actual issues you see or just felt that the callable/middleware way is more flexible (which is possibly true)?

From #81

mostly because it has a smaller dependency tree

We are talking about one dependency: the contract package itself. No other dependencies are required for consumer packages. I guess you meant actual implementations, which are indeed not just single dependencies, but neither Guzzle is.

[bshaffer]

Thank you for the info and clarification @sagikazarmark. Really this comes down to the amount of time to work on this, and the demand of the community.

Our main goal is to get this working and useful. Guzzle6/PSR7 are the fastest ways to accomplish this. Also, I'm sure you'll agree, PR #81 would have required a tremendous amount of work to get into shape. The tests were failing and even smaller things like whitespace issues made it not a viable option.

That being said, this is a community project, and we can open an issue for HTTPlug support, to see how many +1's we receive. I really appreciate the work being done by you guys, and I hope to incorporate your library into this one in the future.

[sagikazarmark]

@bshaffer it wasn't my intention to promote the library or force using it. I don't believe it is a standard (although some PSR could be depend on it), and I definitely don't think there is only one possible solution for problems (that's one of the idea of HTTPlug actually).

Just wanted to clear some things, which I believed to be easily misunderstandable.

I agree that at the current state of the library it requires a big amount of work to make it actually work, and the interfaces are not 100% stable yet, so any code depending on it should not be considered production ready.