• Why should it? This abstract operations class does not say it's REST-specific, so why couldn't we go with gRPC async? We should see default to one of the ones that are supported (have the right dependencies); if both gRPC and REST are possible, sure, we could have a policy as to which one we choose for the default. As per my other comment, if the plan is to do this as we clean up this code, etc., let's add a TODO with link to a tracking issue that includes setting the right default.

• Regardless, I would remove the final clause:

• Also, update the class doc above so instead if "If set to None, a transport is chosen automatically", it says "If set to None, this defaults to 'rest_asyncio'".

I don't think we need a TODO to add the right default. This is an async REST client so we're setting the right default value i.e.rest_asyncio.

What we may instead want to do is update the name / docstring of the class to make it clear that this is specific to async REST.

In future, we may want to spend some time to investigate if we can combine different transport and client class for gRPC and REST that we maintain.

So if this is an async rest client, why do we have a transport parameter at all? What do we do if thetransport is not an async rest transport (ours or user-defined)? Might be worth filing a follow-up issue.

Users can still configure an instance of an async transport class but I agree that it is a bit weird. Can add a note about it in the issue that i file.

Filed:#726

The name of the file and the name of the class do not make it clear that this is REST-specific. So async should work if at least one of { (REST dependencies), (gRPC dependencies) } are available. So it seems to me we should check for both sets of dependencies being absent before we error.

That, at least, when we get to the steady state of having everything implemented and cleaned up. If that's the reason we're not doing that now, let's add a TODO with a link to a tracking issue.

You're right. The name doesn't specify it but it is indeedREST specific. I agree that it's confusing. The name used here is consistent to what we have for the sync REST client / transport. We can have a discussion on what we want to name our async client / transport.

Updating the sync client name would be a breaking change.

AbstractOperationsClient has acompression parameter. Since This abstract class is, I assume, also applicable to gRPC, we should accept that parameter.

AbstractOperationsClient shouldn't have acompression parameter since it's aREST only client. We have a separate client forgRPC.

So if this is an async rest client, why do we have a transport parameter at all? What do we do if thetransport is not an async rest transport (ours or user-defined)? Might be worth filing a follow-up issue.