Route template parameters order cannot be changed even with ODataAttributeRoutingAttribute

[adrien-constant]

Assemblies affected ASP.NET Core OData 8.0.11

Describe the bug Refering to this post from @xuzhg https://stackoverflow.com/questions/72182707/odata-v7-8-should-composite-keys-be-in-alpha-order-or-haskey-when-key-value

Or you can use the attribute routing. In attribute routing, you can set any order in the route template.

I tried with ODataRoutingSample and it didn't work (or I didn't understand something)

Reproduce steps

1. Open the AspNetCoreOData solution
2. Edit ODataRoutingSample.Controllers.PeopleController to inherit from ODataController (which has a ODataAttributeRouting attribute)
3. Launch the ODataRoutingSample project

This request works : http://localhost:64771/People(FirstName='Magazine',LastName='Jingchan')

But this request does not work (404) : http://localhost:64771/People(LastName='Jingchan',FirstName='Magazine')

Additional context I think it is important to allow the key parameters to be specified in any order. I know you can enforce it with the Order property in the model configuration, but since query parameters in MVC can be set in any order, same is expected for the key parameters from the route template.

[julealgon]

@adrien-constant what happens when you don't specify the parameter names? That's supported in OData right? For example:

• http://localhost:64771/People('Magazine', 'Jingchan')

Because of that, there should still be a "well defined order" that can be specified by default.

I do agree that when you are calling with explicit argument names, that it shouldn't matter though. Same as what happens in C# today with named parameters for example: the information to identify each parameter is already there so there is no reason to require the order to be exact too.

[adrien-constant]

I agree order should matter when parameter names are not specified but not when they are. I think the OData lib generates a custom route behind the wheels, would it be possible to generate n routes instead of one ?

FirstName='{keyFirstName}',LastName='{keyLastName'}

and

LastName='{keyLastName'},FirstName='{keyFirstName}'

or have a custom parser that would split the string by comma and map then whatever the order is ?

[julealgon]

I think the OData lib generates a custom route behind the wheels

It does if you don't remove the route convention, otherwise its up to you to define the route using attribute routing.

... would it be possible to generate n routes instead of one ?

FirstName='{keyFirstName}',LastName='{keyLastName'}

and

LastName='{keyLastName'},FirstName='{keyFirstName}'

It definitely would be possible, though I'm not sure that would be the best approach. Keep in mind that this same problem also applies to custom functions, which can take arbitrary numbers of arguments that are passed in a similar manner using GET. I imagine generating every possible permutation as different routes would become kind of a mess very quickly.

or have a custom parser that would split the string by comma and map then whatever the order is ?

I assume it should be possible to create a custom route constraint that takes the parameter names into account and matches any some/endpoint(*) then properly handles the * there. The same route constraint could then be used if you were declaring your own route using attributes (we want to be sure that it works both using conventional routes as well as explicit ones). But I'm not 100% sure myself that's the way to go honestly.

Let's see what OData folks have to say about this one.

[VladDerptastic]

@julealgon So did the OData folks have anything to say on this one?

[julealgon]

@julealgon So did the OData folks have anything to say on this one?

Sorry @VladDerptastic I don't personally have any updates on this as I'm not part of the OData team. You'll have to wait until someone else takes a look at this one.

[VladDerptastic]

@julealgon So did the OData folks have anything to say on this one?

Sorry @VladDerptastic I don't personally have any updates on this as I'm not part of the OData team. You'll have to wait until someone else takes a look at this one.

Of course, apologies for the assumption! I can also see we match on a lot of other issues across oData 8.

[berseus]

Related to #518

[VladDerptastic]

@xuzhg Is there anything in the pipeline to allow support for this (named parameters order irrelevance)? It has been a feature of older versions of oData, and it seems to have been dropped for no explicit good reason.