Is there a design pattern for this case of pair of classes?

This issue comes up frequently in my projects. Suppose that, as an example, I have two interfaces, one that retrieves information from an API and another one that parses this information.

public interface APIClient {...}

public interface APIParser {...}

Now, I may need to have different APIs, so I will have many implementations for the APICLient but each of this implementations will need its own APIParser.

This will lead to this type of structure

public class APIClientA implements APIClient {...}
public class APIParserA implements APIParser {...}

public class APIClientB implements APIClient {...}
public class APIParserB implements APIParser {...}

...
...

So, in general, this would mean that every time I want to add a new type of API, I'll have to create several classes for the same type, and make sure they only communicate with each other and not with the implementation of other types of APIs.

This looks very similar to what Bridge design pattern propose, but this pattern would allow any APIClient to use any APIParser (Am I right ?)

So, is there a better solution? Or maybe this is fine and there is no need to refactor it.