`/$metadata` returns 404 when there's no action methods in ODataController

[pycxu]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

/$metadata returns 404 when there's no action methods in ODataController.

Startup:

    services.AddControllers().AddOData(options => options.Expand().Select().Filter().OrderBy().Count().SetMaxTop(10));
    services.AddApiVersioning(opt =>
    {
        opt.DefaultApiVersion = new Asp.Versioning.ApiVersion(1, 0);
        opt.AssumeDefaultVersionWhenUnspecified = true;
        opt.ReportApiVersions = true;
    }).AddOData(options => options.AddRouteComponents("odata/v{version:apiVersion}"));

Controller:

    public class TestAController : ODataController
    {
        [HttpPost("api/Test")]
        public IActionResult Test()
        {
            return (Created(new[] { new TestA { Id = 1 }, new TestA { Id = 2 } }));
        }
    }

Endpoints:

test: Information: Route: odata/v{version:apiVersion}/$metadata  |  Name: Asp.Versioning.Controllers.VersionedMetadataController.GetOptions (Asp.Versioning.OData)
test: Information: Route: odata/v{version:apiVersion}/$metadata  |  Name: Asp.Versioning.Controllers.VersionedMetadataController.GetMetadata (Asp.Versioning.OData)
test: Information: Route: odata/v{version:apiVersion}  |  Name: Asp.Versioning.Controllers.VersionedMetadataController.GetServiceDocument (Asp.Versioning.OData)

GET http://localhost:57464/odata/v1.0/$metadata returns the metadata;

but if I comment out the actions in Controller, it returns 404 instead.

Controller (with no actions):

    public class TestAController : ODataController
    {
        //[HttpPost("api/Test")]
        //public IActionResult Test()
        //{
        //    return (Created(new[] { new TestA { Id = 1 }, new TestA { Id = 2 } }));
        //}
    }

Expected Behavior

GET http://localhost:57464/odata/v1.0/$metadata should return metadata even there's no ODataController or actions?

Steps To Reproduce

I have attached a repro project for your reference.
Repro.zip

Exceptions (if any)

No response

.NET Version

8

Anything else?

I'm not sure if this is intended or a bug.
Please advise if I'm not doing things correctly.

[commonsensesoftware]

Currently, this is the expected behavior and has been for as long as I can remember. The $metadata endpoint and, hence, MetadataController is driven by the collated set of implemented API versions. If you have no API versions at all, there's no metadata to generate anything from. It could be argued that this is a bug, but I see it more as an impractical edge case. If you're using API Versioning, why would you have zero API versions?

If we accept that it's a bug, what would the fix be? There is no concept of no API version; you must have a discrete set of versions. Even if you didn't receive 404, you'd just get an empty service document. Is that any better? The DefaultApiVersion can be, and sometimes is, used as a fall back given when there are no other versions. The problem here is that it would be a lie. If there are no actions/APIs with that version, why list it?

Another scenario is that you're versioning by URL segment (the unRESTful way). If there are no APIs in 1.0, shouldn't ~/v1/$metadata not exist? I can see how there's a path to opt into yielding an empty service document, but I'm not convinced that is really worth the effort. Since you also allow omitting an API version (which BTW is only meant for backward compatibly), it's a little strange that ~/$metadata returns 404, but - again - it would just be an empty service document.

There is also another known edge case. If all of your controllers are version-neutral, the same problem will arise. I believe there's some old issues about that. It's the same fundamental problem. A version-neutral API allows any known API version, including none at all. For the purposes of discovery, which is used for $metadata and OpenAPI, this means that a version-neutral API appears in every defined API version. Unfortunately, if there are no formally defined API versions, then there is nothing to tie them to. This also begs the question "If all of your APIs are version-neutral, then why do you need API Versioning?"

Succinctly, there are a couple of sharp edges with OData discovery and you've hit them. I'm open to providing a better experience, but I'm not convinced - yet - that much needs to be done to change the current behavior because these are effectively nonsensical use cases.

[pycxu]

Thanks for the detailed explanation.
I agree that this seems an impractical edge case having no ODataController or action methods.

The reason I'm raising this is because it worked for our project when we were using Microsoft.AspNetCore.OData.Versioning.

FYI, we are upgrading .NET from 6 to 8 and migrating Microsoft.AspNetCore.OData.Versioning to Asp.Versioning.OData.

After reading your comment and this sample, I am able to get all projects working with IModelConfiguration except one project which does not have a ODataController.

This is how we configure OData before:

    public void ConfigureServices(IServiceCollection services)
    {
        services.AddApiVersioning(opt =>
        {
            opt.DefaultApiVersion = new ApiVersion(1, 0);
            opt.AssumeDefaultVersionWhenUnspecified = true;
            opt.ReportApiVersions = true;
        });
        services.AddOData().EnableApiVersioning();
        services.AddMvc(options =>
        {
            options.EnableEndpointRouting = false;
        });
    }


    public void Configure(IApplicationBuilder app, IHostEnvironment env, ILoggerFactory loggerFactory, VersionedODataModelBuilder modelBuilder)
    {

        app.UseHttpsRedirection();
        app.UseCors();
        app.UseMvc();
        app.UseMvc(b =>
        {
            var models = modelBuilder.GetEdmModels();
            b.Select().Expand().Filter().OrderBy().MaxTop(100).Count();
            b.MapVersionedODataRoutes("dataapi-odata", "odata/v{version:apiVersion}", models, builder => { });
        });
    }

The $metadata works even there's no ODataController or action methods.

See attached

Repro - AspNetCore.OData.Versioning.zip

[commonsensesoftware]

There could be a difference between the major versions here. There were some internal changes to routing that fixed a different class of issues that might have caused the difference. It's been a few years now so I don't remember off the top of my head. The correct, bare minimum setup should be something like:

services.AddControllers().AddOData();
services
    .AddApiVersioning(opt =>
     {
         opt.AssumeDefaultVersionWhenUnspecified = true;
         opt.ReportApiVersions = true;
     })
    .AddOData()
    .AddODataApiExplorer();

You do not need to use ODataController. A controller is included with OData versioning features if it applies ODataAttributeRoutingAttribute, which ODataController does. You can create any controller you like or even a bare metal implementation as long as that attribute is applied.

Is there are reason to apply OData without using OData? It seems like the solution to your problem is to remove the OData support or make your controller support OData. Is the question how to implement an empty service document for the $metadata endpoint or is there another fundamental question? There are can be changes, even breaking changes, across major version releases. I'm try to zero in on your ask so I can better guide you. If the question is "How to I create an empty $metadata endpoint?", I'm not 100% sure that's is still possible. If that is your use case, I'd like to know why.

[pycxu]

After checking our endpoints and ModelConfiguration, I found that OData endpoints are generated even without using ODataController or ODataAttributeRoutingAttribute via FunctionConfiguration.

For example,

Controller:

    [Route("api/[controller]")]
    [ApiController]
    public class TestAController : Controller //Not using ODataController or ODataAttributeRoutingAttribute
    {

        [EnableQuery]
        [HttpGet]
        public async Task<List<TestA>> Find() // OData endpont, however $metadata wont work
        {

            return new List<TestA>
            {
                new TestA{ Id = 1, Name = "1"},
                new TestA{ Id = 2, Name = "2"},
                new TestA{ Id = 3, Name = "3"}
            };
        }
    }

ModelConfiguration:

    public class ModelConfiguration : IModelConfiguration
    {
        ///
        public void Apply(ODataModelBuilder builder, Asp.Versioning.ApiVersion apiVersion, string routePrefix)
        {
            builder.EntitySet<TestA>("TestA").EntityType.HasKey(k => k.Id);
            builder.EntityType<TestA>().Collection.Function("Find").ReturnsCollection<TestA>();
        }
    }

Below odata endpoints are generated:

test: Information: Route: odata/v{version:apiVersion}/TestA/Default.Find  |  Name: Repro.ODataControllers.TestAController.Find (Repro-8)
test: Information: Route: odata/v{version:apiVersion}/TestA/Find  |  Name: Repro.ODataControllers.TestAController.Find (Repro-8)
test: Information: Route: odata/v{version:apiVersion}/$metadata  |  Name: Asp.Versioning.Controllers.VersionedMetadataController.GetOptions (Asp.Versioning.OData)
test: Information: Route: odata/v{version:apiVersion}/$metadata  |  Name: Asp.Versioning.Controllers.VersionedMetadataController.GetMetadata (Asp.Versioning.OData)
test: Information: Route: odata/v{version:apiVersion}  |  Name: Asp.Versioning.Controllers.VersionedMetadataController.GetServiceDocument (Asp.Versioning.OData)

• odata/v{version:apiVersion}/$metadata (from Asp.Versioning.OData)
• odata/v{version:apiVersion}/TestA/Find (from FunctionConfiguration ?)

The Find() odata endpoint also works with odata qeury

GET http://localhost:57464/odata/v1.0/TestA/Find?%24orderby=id&%24top=2&%24count=true

{
  "@odata.context": "http://localhost:57464/odata/v1.0/$metadata#Collection(Repro.ODataControllers.TestA)",
  "@odata.count": 3,
  "value": [
    {
      "id": 1,
      "name": "1"
    },
    {
      "id": 2,
      "name": "2"
    }
  ]
}

But the $metadata won't work (404 Not Found) even there are actual working odata endpoints.

Btw, with our old odata setup, the Find endpoint is mapped to Find instead of Find().
So I have to set EnableNonParenthesisForEmptyParameterFunction to true now; is this also expected?

            services.AddControllers().AddOData(options => {
                options.EnableQueryFeatures(maxTopValue);

                //`odata/v{version:apiVersion}/TestA/Find` instead of `odata/v{version:apiVersion}/TestA/Find()`
                options.RouteOptions.EnableNonParenthesisForEmptyParameterFunction = true; 
            });

---

Repro with test http file

Repro-FunctionConfiguration.zip

[commonsensesoftware]

I think I see. It looks like you are in some OData land. When you're in this situation, I only expect query option binding to work. You are not necessarily conforming to OData routing conventions or wire formats. If you haven't already, I'd recommend turning on app.UseODataRouteDebug(); so you can print out the mapped routes and see if you're actually mapping to OData.

I've tested this scenario against the Some OData OpenAPI example. The /$metadata endpoint returns 404, which is actually what I expect. You're not using [all of] OData at that point. There is no EDM that be used for the endpoint or code generation. If you want /$metadata, then you need to conform to OData. If you just want some of the query capabilities, but your own API without being fully OData-compliant, you can continue down your path using OpenAPI/Swagger.

Aside: If you're building an API I would recommend ControllerBase over Controller.

[pycxu]

Thanks for the explanation and suggestions. It makes more sense to me now.