PHPoAuthLib
PHPoAuthLib copied to clipboard
daviddesberg
Response code
We use the service to request data from services like Facebook, Yammer and Twitter using the request function. But Yammer only return's http error codes and no body. I suggest to make a response object return from the http clients with the ability to get the response and code and maybe more like the http response headers.
ping @PeeHaa thoughts on using something like Symfony HttpFoundation or no point in introducing another dependency?
I like the idea of returning a response object, but I don't like introducing an external dependency.
@PeeHaa I agree, but I also don't like rolling our own response object when there's a widely used implementation out there. It might be useful to have interoperability. Not sure if that makes it worth introducing the dependency though.
In the pull request I used the Symfony BrowserKit Response as an example for implementing it. https://github.com/symfony/symfony/blob/master/src/Symfony/Component/BrowserKit/Response.php
Honestly, I'd rather have an approach to this as it's done with the session handler. Having the Interface, Abstract implementation, simple implementation and then, who is using a framework and willing to use the framework's HTTP implementation could use an adapter or something like that.
I use HttpFoundation quite a lot, however it's big dependency you would be pulling just to use the response object. I think it's more catered to your own web server's response, not external service's response. Alot of issues that come up here have something to do with the clients. Perhaps we should integrate Guzzle as a proper HTTP client for better debugging or Artax so curl is no longer necessary. Httpful is also quite a good lightweight alternative.
There was an GuzzleClient but is removed about a year ago? https://github.com/Lusitanian/PHPoAuthLib/commit/92edc091c826ecea50f32e0c583eee034a66ebb9
The commit message indicates working on Artax client. Problem being is that Artax is 5.4 and up.
@cmodijk @CMCDragonkai My current thought is implementing a guzzle-based client implementation in a separate repo and offering it as a suggested install. Thoughts?
@Lusitanian I had the exact sam thought on implementing if in a second repo but the ClientInterface still excepts a string and not the Guzzle Reponse object and the Guzzle response object __toString returns the body with the headers.
@Lusitanian Next to that thought I want to ceate a guzzle plugin for PHPoAuthLib maybe inside the same repo as the lusitanian/oauth-guzzle. The guzzle plugin allows modifying the guzzle object before sending it with this we could add the oauth header tokens to the guzzle request object and would be able to use the full guzzle client to do al the requests to the apis. My problem with this was that the there is no way to retrieve the acces token header (or request token) because the methods al protected or private. https://github.com/Lusitanian/PHPoAuthLib/blob/master/src/OAuth/OAuth2/Service/AbstractService.php#L140
Just like the current oauth 1 native guzzle plugin https://github.com/guzzle/guzzle/blob/master/src/Guzzle/Plugin/Oauth/OauthPlugin.php#L83
Sounds good. If Guzzle will be able to solve a lot of the problems here, it'll probably be the recommended route anyway. PHPoAuthLib can take advantage of improvements to Guzzle for free, the HTTP protocol is really monolithic and different services may do things differently and sometimes incorrectly. However I fear that with so many clients using different methodologies: Stream, Curl, Guzzle, it may get difficult to support all of them, and if something is wrong in one of the clients, there'll be issues popping here about that specific client. I would prefer to focus on just one client implementation, but open up an interface to allow others to add their own clients if they feel like it. This allows us to focus our energy on one good client, and if problems come up here regarding the client, we know exactly where to look.
One thing though, make sure to expose the raw Guzzle object if there needs to be some specific work done on them.
This is a basic implementation for a GuzzleClient https://gist.github.com/cmodijk/7608340 I have not tested it yet. I will work an that this weekend and to create a new repository to bridge Guzzle and PHPoAuthLib. But I think the PHPoAuthLib still needs the response object. For my idea for the Guzzle plugin there needs to by a way to sign the requests generated by Guzzle this is now part of the AbstractService any ideas on that?.
Got the Guzzle client working in a second repo https://github.com/JCID/PHPoAuthLib-Guzzle. Still need a way to create the Guzzle Plugin.
Another way to go is to add a $asString and let clients like Guzzle return the response object if this is set to false. I have created a example implementation on this. https://github.com/JCID/PHPoAuthLib/commit/38c69199c45358366c874ec781f7f23ba4ae0f7b
I just created a basic Guzzle client at https://github.com/Lusitanian/PHPoAuthLib/pull/155
It returns the raw body in normal circumstances and throws a GuzzleException when the HTTP status codes is non-2XX.
It also now provides some methods to get at the Guzzle Client directly, and the last Guzzle Response. For instance, I can get the last HTTP response code via:
$statusCode = $myService->getHttpClient()->getLastResponse()->getStatusCode();
I'm using this in some active development and it works well for my purposes. I'm interested in other opinions.
Any news regarding this? I'm in a similar situation as @cmodijk - I'm using LinkedIn's Groups API to post to a group but unfortunately, unlike other API methods (Linkedin's API seems quite a mashup of different ways of thinking), the API call doesn't return any body, just a header with the URL of the created post. Since I can't access the response from PHPoAuthLib, I'm stuck.
I think, we have to use PSR-7 for response object and probably PSR-18 for client.
