OData Client generates one expand and select per field

To make clear the intent, OP is asking whether this part:

?$expand=Products($select=Name),Products($select=Description)&$select=Id,Name

can be shortened to only this (and how to do it):

?$expand=Products($select=Name,Description)&$select=Id,Name

For the answer we need to look actually in the OData standard - URL conventions - $expand. There is quite detailed description about the $expand category and how it can be used. For us is important this paragraph:

> A path consists of segments separated by a forward slash (/). Segments are either names of single- or collection-valued complex properties, instance annotations, or type-cast segments consisting of the qualified name of a structured type that is derived from the type identified by the preceding path segment to reach properties defined on the derived type.

> A path can end with
> - the name of a stream property to include that stream property,
> - a star (*) to expand all navigation properties of the identified structured instance, optionally followed by /$ref to expand only entity references, or
> - a navigation property to expand the related entity or entities, optionally followed by a type-cast segment to expand only related entities of that derived type or one of its sub-types, optionally followed by /$ref to expand only entity references.
> - an entity-valued instance annotation to expand the related entity or entities, optionally followed by a type-cast segment to expand only related entities of that derived type or one of its sub-types.

In normal people language: When you want to select only particular properties from an object (You are trying to select only 2 properties - Name, Description), OData standard considers them both to be navigation properties and we must add them separately:

$expand=Products($select=Name),Products($select=Description)

The only other possible solution is to take whole object, which returns all the data and this bit of query looks like:

$expand=Products

So the intended ?$expand=Products($select=Name,Description) actually doesn't follow this standard / would break the definition of the standard ~ would not be valid.

And just to be super clear, it would be possible to edit this URI by hand inside the method that OP has already used (showing naive implementation), but it would not follow the standard/would not make sense:

var container = new Container(new Uri("http://localhost:5184/odata"));
container.BuildingRequest += Container_BuildingRequest;

void Container_BuildingRequest(object? sender, Microsoft.OData.Client.BuildingRequestEventArgs e)
{
    var newUri = e.RequestUri.ToString()
       .Replace("$expand=Products($select=Name),Products($select=Description)",
                "$expand=Products($select=Name,Description)");
    e.RequestUri = new Uri(newUri);
}

I have also struggled with this in the past, in .Net 7 the OData Client does not yet properly resolve projections formulated via LINQ expressions, the resulting URI is wrong if you request more than one property from a related entity.

The solution provided by @tatranskymedved where you modify the Uri in-flight is one that I myself have used in the past for one-off structures, however I often have to manually parse the response structure because the OData Client validates the $metadata in the response.

In the end I settle with constructing the query options directly, seeing that this requires the same level of knowledge and effort as modifying the URI, then if a projection into an anonymous type is required we can use LINQ to objects after the data has been loaded from the server:

var query = container.Categories.AddQueryOption("$expand","Products($select=Name,Description)")
                                .AddQueryOption("$select", "Id,Name");
var projectedData = query.ToList().Select(c => new
{
    c.Id,
    c.Name,
    Products = c.Products.Select(p =>
        new
        {
            p.Name,
            p.Description
        }
    )
}).ToList();

The output will be the expected form:

http://localhost:5184/odata/Categories?$expand=Products($select=Name,Description)&$select=Id,Name

This works because the query.ToList() will resolve the response into instances from the proxy types defined in the container, with the omitted properties left uninitialized.
> Update: Lets see that in more detail
>
> // force OData query to resolve into the concrete types first
> var odataResult = query.ToList();
>
> // then project into custom DTO to remove the properties that were not loaded
> var projectedData = odataResult.Select(c => new
> {
> c.Id,
> c.Name,
> Products = c.Products.Select(p =>
> new
> {
> p.Name,
> p.Description
> }
> )
> }).ToList();

In this state it is safer for your application if you then project into a DTO or anonymous type to avoid confusion over the uninitialized fields being in that state because they were not requested from the server or because that is their actual value on the server.

• Even though that metadata is programmatically available, most developers consuming this output would not bother to check for it in their consuming logic.

A final quick note in your controller logic. Because the OData entity set for the Category type is Categories:

var modelBuilder = new ODataConventionModelBuilder();
modelBuilder.EntitySet<Category>("Categories");

you need to change your controller name to CategoriesController. The standard convention is that your controller class name should be in the form $"{EntitySet}Controller" for it to be correctly resolved.

public class CategoriesController : ODataController
{
    ...

    [EnableQuery]
    public ActionResult<IEnumerable<Category>> Get()
    {  
        return Ok(customers);
    }
}

Update:

A comment was raised about how this is still a workaround and not a solution. The best practise solution to projections in OData client is to NOT project into nested type structures. The current support for nested projections is intended to support using a projection to select a single property on the navigation entity to represent that object, in general client application development this might be a Title, Name or Description property.

You can facilitate complex common projections on the server-side through complex type inheritance, lets say that Product inherited from a DescriptorBase class then you could us .OfType<DescriptorBase>() to constrain the navigation properties, but at the time of me writing this, there is no support for this in the LINQ to OData url resolver.

That means that for all complex projections .AddQueryOption() IS the solution.

My only issue with using .AddQueryOption() alone is that it leaves the initialized fields in an accessible state in the codebase. It does however mimic the experience of javascript client-side development. I often change my scaffolding templates to throw an exception if an un-initialised field value is accessed as a safety mechanism, but that is only experienced at runtime and it's too easy for other developers to assume that the field is usable and hard to identify at design time if we should be expecting a value or not.

That is why I include the step of manually projecting to the expected DTO type, it hides the complexity of the call and any confusion about providing values that should not be accessed. It is not necessary to make the OData call work, but it does reduce long term maintenance of the code.

From an engineering point of view, the ability for you to query your API at free will from any point in your codebase is an anti-pattern. You should try to constrain the LINQ to OData through fixed contract endpoints because you are interfacing with an external system. LINQ is fun and is very easy to get started with and a lot harder to master, much like LINQ to SQL. (although significantly more community effort has gone into supporting complex projections to SQL) The solution offered here encapsulates the complexity of the LINQ and the OData query into a fixed output that the rest of your codebase can consume. You could extend queries like this into your container class either through partial classes or extension methods, that would make consuming this type of query feel more natural to consuming code.

This solution also supports complex OData queries and projections that cannot be translated from LINQ, like $apply and $compute so even if you start to write your own LINQ to OData URI resolver, there will always be exceptions and this still is going to present a viable solution to those exceptions.

Constraining the calls to your external API through pre-defined expressions/queries and DTOs makes it easier to decouple and test your code-base. It feels like more effort than it is worth for small apps or single dev teams, but it is non-negotiable for successfull management of larger teams or applications. Getting into the habit now will prepare you for the future.