API Design: Querying a sub-resource

Question

We have a resource which could be modeled as a nested object

GET /A/
[
  {
    "name": "my_a",
    "B": [
      {"name": "my_b", "address": "0xbeef"}
    ]  
  }
]

or a sub resource, like

GET /A/my_a/B
[
  {
    "name":"my_b", "address": "0xbeef"
  }
]

Our customers want a way to query for objects of type A based on properties of type B, e.g. "get me all the A objects who have B objects with name 'my_b'".

It seems preferable to write the API using the "B as a sub-resource" style of writing because it lends itself to pagination if there are many B object types. Additionally, retrieving B objects can be expensive, so if only some clients are interested in B, it makes sense to required the seperate calls to retrieve subresource B. However, it also seems strange to allow users to query on a sub resource if the sub resource is not returned in the results.

For example, a query feels quite natural when in the form:

GET /A?query=B.address[equals]0xbeef
[
  {
    "name": "my_a",
    "B": [
      {"name": "my_b", "address": "0xbeef"}
    ]  
  }
]

but less so when the query looks like

GET /A?query=B.address[equals]0xbeef
[
  {
    "name": "my_a"
  }
]

A compromise I'm considering is using the nested approach but not include the B objects by default. A query parameter can expose B. So,

GET /A?query=B.address[equals]0xbeef&include_b=true
[
  {
    "name": "my_a",
    "B": [
      {"name": "my_b", "address": "0xbeef"}
    ]  
  }
]

I researched "REST, nested objects, querying" and found examples. Most of these examples included the subresource as a nested object, the include_b parameter seems unique to my design.

So, SO, I'm looking for general feedback on this approach, and to see if this is a common problem with a known solution. Curious to hear what comes back.

edit 1: Updated the example to show that querying can be on arbitrary properties.

Answer 1

As @RomanVottner pointed out, I'm actually not designing a RESTful API. Instead, the API is closer to an RPC translated to use HTTP/JSON. In fact, my team follows the Google API Design guide which itself is dictating how to write GRPC APIs which are then (I presume) automatically translated into web endpoints.

So, at the end of the day, I have not had my style question answered, other than to learn that my question wasn't accurate. I will most likely use the solution I purposed in the question.