Terminology

[sagikazarmark]

I am thinking about the following:

We could make adapter/client a set of interfaces which are recommended for client implementations. This way if an HTTP Client PSR is created once, we already have something.

The adapter naming is useful in the context of creating adapters wrapping clients. But for the long term, clients themselves should have a common interface which makes the adapter naming a bit vague.

I remember @jeromegamez mentioned something similar.

What do you think?

[hannesvdvreken]

Not sure, I believe the interfaces Http\Adapter\HttpAdapter and Http\Client\HttpClient are super clear and minimal (does not violate interface segregation principle at all!).

What different interface would you suggest?

[sagikazarmark]

Actually, I would like to preserve the two separated interfaces. They are fine. My particular idea is to rename the adapter to something which just could be used as a client itself. For example Guzzle 7 could implement what we call Adapter interface (and the Client interface as well). From this point, the adapter is not an adapter anymore, but the client itself.

So maybe we could call these things PsrHttpClient and HttpClient. Actual adapters themselves can still be called adapters. But the base interface should not suggest if it is implemented by an adapter or an actual HTTP Client.

[hannesvdvreken]

Good idea! Although I don't know if adoption is high enough and whether enough http client maintainers know about this interface.

[sagikazarmark]

The point is that we make it possible. Also, if this interface gets to a PSR once, we don't have to change our entire architecture....better do it now.

[sagikazarmark]

The two interfaces are good enough IMO. We just need proper naming. Also, I am thinking about to put the interfaces into one package. This also solves the exception problem I am struggling with: currently the adapter and the client interface have separate exceptions which does not make much sense IMO. They serve the same purpose.

[hannesvdvreken]

I agree. Also on the same package for both interfaces. And where would the client implementation go?

[sagikazarmark]

Which client implementation? This one?

Currently I only have an imaginary state in my mind (as I explained it here), but I don't really have an exact implementation/naming strategy (yet).

@ddeboer can you also join the discussion? You've already used the adapter, I am curious about your points on this.

[hannesvdvreken]

Yes. php-http/adapter, php-http/adapter-client and php-http/client could be one repository imho. Btw I'm doing a talk at Laracon EU in 2 weeks where I will mention php-http.

[sagikazarmark]

Well, I think interfaces should go into one package, implementation into
another. Interfaces are somewhat connected and they can be used for several
cases:

• Implementing an adapter
• Implementing them in an actual client
• Using it in an SDK or something

In these cases implementation is not needed at all.

Also, I am thinking about adding a third interface which extends both
PsrHttpClient and HttpClient for easy typehinting.

[hannesvdvreken]

Agreed.

Like what? Likes this:

namespace Http\Client;

interface PsrHttpClient
{
...
}

namespace Http\Client;

interface HttpClient
{
...
}

namespace Http\Client;

interface Client extends PsrHttpClient, HttpClient
{
}

I would actually work on

1. Finalising interfaces and naming
2. Tagging releases
3. Adoption by other packages/sdks
4. More adapters

In that order. Because waiting on the FIG to for an approved version... It could be useful to make something that is already greatly adopted so they will consider using great portions (if not all) of this HTTP adapter interface for their interface.

[sagikazarmark]

Actually I would prefer if Client would extend HttpClient and
PsrHttpClient. Seems more logical to me.

My plan is to merge the client and the adapter package. But we should
preserve the adapter package's history. The client one is pretty new
without relevant history.

[dbu]

imho from a user point of view, i don't care whether i use an adapter to some non php-http complient client or a client directly. so a big +1 on merging those.

if an adapter needs additional methods for the configuration or such, this is an implementation detail for adapter builders but client libraries that just consume the http client should not need to care about this.

[sagikazarmark]

Let's continue discussion in #40