Http\Client and dependent components

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Http\Client and dependent components

DeNix
Hi all,

IMHO Http\Client not in best shape, but I guess no one (me included)
will have time to refactor it properly before RC
So I thought, mabe we could define following interfaces to let
developers use custom HTTP clients

1)
Http\ClientInterface with  common HTTP methods
Http\ClientAwareInterface with set/getClient() methods

2) update ZendService components, OpenId, OAuth etc. to use iterface and
not http client directly

what do you think?

Denis

Reply | Threaded
Open this post in threaded view
|

Re: Http\Client and dependent components

ralphschindler
> 2) update ZendService components, OpenId, OAuth etc. to use iterface and
> not http client directly

What do you mean? That the service components simply implement the
Http\ClientInterface?  I don't what the benefit is there.

-ralph

Reply | Threaded
Open this post in threaded view
|

Re: Http\Client and dependent components

DeNix
20.07.2012 23:00, Ralph Schindler пишет:
>> 2) update ZendService components, OpenId, OAuth etc. to use iterface and
>> not http client directly
>
> What do you mean? That the service components simply implement the
> Http\ClientInterface?  I don't what the benefit is there.
>
I mean service components will implement Http\ClientAwareInterface, so
they could be injected with custom HTTP client that implements
Http\ClientInterface

Now HTTP client basically plays the same role as logger, cache, db
Those components define interfaces, and could be partly or fully
replaced with alternative implementation
(i.e I18n\Translator could be injected with anything implementing
Cache\StorageInterface)
I'd like to extend it to HTTP client

Denis

Reply | Threaded
Open this post in threaded view
|

Re: Http\Client and dependent components

ralphschindler
Currently, the Zend Service components have been moved, each, to their
own repository on github, check that out here:

http://github.com/zendframework

I've already updated each of the service components to use constructor
injection for injecting the HttpClient.  There is also a setHttpClient
in most cases in case you need to replace the http client after the fact.

Most of these services need some TLC at the moment.

-ralph

On 7/20/12 2:15 PM, Denis Portnov wrote:

> 20.07.2012 23:00, Ralph Schindler пишет:
>>> 2) update ZendService components, OpenId, OAuth etc. to use iterface and
>>> not http client directly
>>
>> What do you mean? That the service components simply implement the
>> Http\ClientInterface?  I don't what the benefit is there.
>>
> I mean service components will implement Http\ClientAwareInterface, so
> they could be injected with custom HTTP client that implements
> Http\ClientInterface
>
> Now HTTP client basically plays the same role as logger, cache, db
> Those components define interfaces, and could be partly or fully
> replaced with alternative implementation
> (i.e I18n\Translator could be injected with anything implementing
> Cache\StorageInterface)
> I'd like to extend it to HTTP client
>
> Denis
>

Reply | Threaded
Open this post in threaded view
|

Re: Http\Client and dependent components

DeNix
21.07.2012 0:28, Ralph Schindler пишет:
> Currently, the Zend Service components have been moved, each, to their
> own repository on github, check that out here:
>
> http://github.com/zendframework
I'm well aware of that
>
> I've already updated each of the service components to use constructor
> injection for injecting the HttpClient.  There is also a setHttpClient
> in most cases in case you need to replace the http client after the fact.
>
>
well that's my point, it would be nice to have
setHttpClient(Zend\Http\ClientInterface $client) intead of
setHttpClient(Zend\Http\Client $client)
to enable alternative implementations, like the rest of the framework
components do with cache, logger, session etc

>
> -ralph
>
> On 7/20/12 2:15 PM, Denis Portnov wrote:
>> 20.07.2012 23:00, Ralph Schindler пишет:
>>>> 2) update ZendService components, OpenId, OAuth etc. to use
>>>> iterface and
>>>> not http client directly
>>>
>>> What do you mean? That the service components simply implement the
>>> Http\ClientInterface?  I don't what the benefit is there.
>>>
>> I mean service components will implement Http\ClientAwareInterface, so
>> they could be injected with custom HTTP client that implements
>> Http\ClientInterface
>>
>> Now HTTP client basically plays the same role as logger, cache, db
>> Those components define interfaces, and could be partly or fully
>> replaced with alternative implementation
>> (i.e I18n\Translator could be injected with anything implementing
>> Cache\StorageInterface)
>> I'd like to extend it to HTTP client
>>
>> Denis
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: Http\Client and dependent components

weierophinney
Administrator
-- Denis Portnov <[hidden email]> wrote
(on Saturday, 21 July 2012, 01:40 AM +0400):

> 21.07.2012 0:28, Ralph Schindler пишет:
> >Currently, the Zend Service components have been moved, each, to
> >their own repository on github, check that out here:
> >
> >http://github.com/zendframework
> I'm well aware of that
> >
> >I've already updated each of the service components to use
> >constructor injection for injecting the HttpClient.  There is also
> >a setHttpClient in most cases in case you need to replace the http
> >client after the fact.
> >
> >
> well that's my point, it would be nice to have
> setHttpClient(Zend\Http\ClientInterface $client) intead of
> setHttpClient(Zend\Http\Client $client)
> to enable alternative implementations, like the rest of the
> framework components do with cache, logger, session etc

I think this makes sense. Can you give a concrete example of what
methods would be in the interface, though?

One aspect that I'm unsure of is a "getHeaders()"; since PHP does not
enforce return types, we'd have to potentially check the return against
known interfaces. However, that's not necessarily a show stopper.


> >On 7/20/12 2:15 PM, Denis Portnov wrote:
> >>20.07.2012 23:00, Ralph Schindler пишет:
> >>>>2) update ZendService components, OpenId, OAuth etc. to use
> >>>>iterface and
> >>>>not http client directly
> >>>
> >>>What do you mean? That the service components simply implement the
> >>>Http\ClientInterface?  I don't what the benefit is there.
> >>>
> >>I mean service components will implement Http\ClientAwareInterface, so
> >>they could be injected with custom HTTP client that implements
> >>Http\ClientInterface
> >>
> >>Now HTTP client basically plays the same role as logger, cache, db
> >>Those components define interfaces, and could be partly or fully
> >>replaced with alternative implementation
> >>(i.e I18n\Translator could be injected with anything implementing
> >>Cache\StorageInterface)
> >>I'd like to extend it to HTTP client
> >>
> >>Denis
> >>
> >
>

--
Matthew Weier O'Phinney
Project Lead            | [hidden email]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
Reply | Threaded
Open this post in threaded view
|

Re: Http\Client and dependent components

DeNix
21.07.2012 2:17, Matthew Weier O'Phinney пишет:

>
>> well that's my point, it would be nice to have
>> setHttpClient(Zend\Http\ClientInterface $client) intead of
>> setHttpClient(Zend\Http\Client $client)
>> to enable alternative implementations, like the rest of the
>> framework components do with cache, logger, session etc
> I think this makes sense. Can you give a concrete example of what
> methods would be in the interface, though?
>
> One aspect that I'm unsure of is a "getHeaders()"; since PHP does not
> enforce return types, we'd have to potentially check the return against
> known interfaces. However, that's not necessarily a show stopper.
>
True, but same with any method defined by interface that should/could
return an object

So,
one approach could be is just to go with current stack and have it like
this:
https://gist.github.com/3153907#file_client_interface_alt.php

Another approach is to define HTTP Request/Response interfaces:
https://gist.github.com/3153907#file_http_interfaces.php
send() here basically acts as dispatch()

in addition static client interface could be defined also:
https://gist.github.com/3153907#file_static_client_interface.php
but this will require some work on implementing side to check $uri and
$headers params

Denis
Reply | Threaded
Open this post in threaded view
|

Re: Http\Client and dependent components

harikt
This post has NOT been accepted by the mailing list yet.
In reply to this post by DeNix

well that's my point, it would be nice to have
setHttpClient(Zend\Http\ClientInterface $client) intead of
setHttpClient(Zend\Http\Client $client)
to enable alternative implementations, like the rest of the framework
components do with cache, logger, session etc


So isn't it a good idea with no interface on setHttpClient() so we can use someother Http client ? 

Eg  : Aura.Http ?

Thank you
Hari K T http://harikt.com
Reply | Threaded
Open this post in threaded view
|

Re: Http\Client and dependent components

ralphschindler
In reply to this post by DeNix
So, there are a lot of variables to balance here.  I'm not opposed to
having a ClientInterface provided that there are well defined use cases
that support having an interface ... which basically means that a
reasonable alternate implementation might exist.

Keep in mind, if the interfaces are living inside Zend\Http, then you
already have a dependency on the Zend\Http component, and real
implementations are already available to issue and receive Http requests
and responses.  In addition, Zend\Http\Client has no dependencies that
require configuration to be utilized.  This is why all services classes
can and do create an instance of Zend\Http\Client if one has not been
provided - it just works.

"Well defined use case": basically what we're getting at here is that,
from my perspective, building and sending HTTP requests and parsing HTTP
responses is mostly implementation details.  Those implementation
details are exposed through a fairly large API (you have to deal with
headers and their various formats, as well as the implications of said
headers on a particular body.)  That said, since the problem area is
non-trivial, the likelyhood of someone starting with
Zend\Http\ClientInterface and implementing out a full solution that will
work with all expected use cases of ZendService classes approaches nil
quickly.

So, that said, perhaps we should start by discussing the Zend\Stdlib
parts (after all Zend\Http\Client implements Dispatchable, but even
there, I'm not sure how useful that is at this point), then move onto
what the Client looks like, then decide if there really needs to be
interface requirements for Header, Request, and Response.

-ralph


On 7/20/12 7:05 PM, Denis Portnov wrote:

> 21.07.2012 2:17, Matthew Weier O'Phinney пишет:
>>
>>> well that's my point, it would be nice to have
>>> setHttpClient(Zend\Http\ClientInterface $client) intead of
>>> setHttpClient(Zend\Http\Client $client)
>>> to enable alternative implementations, like the rest of the
>>> framework components do with cache, logger, session etc
>> I think this makes sense. Can you give a concrete example of what
>> methods would be in the interface, though?
>>
>> One aspect that I'm unsure of is a "getHeaders()"; since PHP does not
>> enforce return types, we'd have to potentially check the return against
>> known interfaces. However, that's not necessarily a show stopper.
>>
> True, but same with any method defined by interface that should/could
> return an object
>
> So,
> one approach could be is just to go with current stack and have it like
> this:
> https://gist.github.com/3153907#file_client_interface_alt.php
>
> Another approach is to define HTTP Request/Response interfaces:
> https://gist.github.com/3153907#file_http_interfaces.php
> send() here basically acts as dispatch()
>
> in addition static client interface could be defined also:
> https://gist.github.com/3153907#file_static_client_interface.php
> but this will require some work on implementing side to check $uri and
> $headers params
>
> Denis

Reply | Threaded
Open this post in threaded view
|

Re: Http\Client and dependent components

DeNix
26.07.2012 0:33, Ralph Schindler пишет:

> So, there are a lot of variables to balance here.  I'm not opposed to
> having a ClientInterface provided that there are well defined use
> cases that support having an interface ... which basically means that
> a reasonable alternate implementation might exist.
>
> Keep in mind, if the interfaces are living inside Zend\Http, then you
> already have a dependency on the Zend\Http component, and real
> implementations are already available to issue and receive Http
> requests and responses.  In addition, Zend\Http\Client has no
> dependencies that require configuration to be utilized.  This is why
> all services classes can and do create an instance of Zend\Http\Client
> if one has not been provided - it just works.
As far as I understand for MVC application dependency on Zend\Http is
there already (Http\PhpEnvironment\Request)

>
> "Well defined use case": basically what we're getting at here is that,
> from my perspective, building and sending HTTP requests and parsing
> HTTP responses is mostly implementation details.  Those implementation
> details are exposed through a fairly large API (you have to deal with
> headers and their various formats, as well as the implications of said
> headers on a particular body.)  That said, since the problem area is
> non-trivial, the likelyhood of someone starting with
> Zend\Http\ClientInterface and implementing out a full solution that
> will work with all expected use cases of ZendService classes
> approaches nil quickly.
While I agree that it's mostly about implementation details, I'm looking
at Zend\Cache and tons of interfaces it provides, and it seems that
implementing it for HTTP client is not that complex. Also HTTP protocol
itself is well described by standards.
>
> So, that said, perhaps we should start by discussing the Zend\Stdlib
> parts (after all Zend\Http\Client implements Dispatchable, but even
> there, I'm not sure how useful that is at this point), then move onto
> what the Client looks like, then decide if there really needs to be
> interface requirements for Header, Request, and Response.
Anyway, It looks like there is no time left for that before RC. So i
guess I outline the idea later as RFC for the next major version.

Thanks
Denis