Howe to define a custom error message when a non existent version is attempted.

[The-Futurist]

If I submit a test POST to my service and specify a version like v1.2 when the service only supports v1.0 and v2.0 then I see a 404 response and nothing else (this is from Insomnia):

I'd like to have a meaningful message returned. When I searched about this I found many posts about this kind of approach:

builder.Services.AddApiVersioning(options =>
{
    options.ReportApiVersions = true;
    options.ApiVersionReader = new UrlSegmentApiVersionReader();
    // This is the key line to use your custom provider
    options.ErrorResponses = new ApiVersioningErrorResponseProvider(); 
})
.AddMvc()
.AddApiExplorer(options =>
{
    options.GroupNameFormat = "'v'VVV";
    options.SubstituteApiVersionInUrl = true;
});

However there is no property named ErrorResponses nor type named ApiVersioningErrorResponseProvider so I suspect this is old, so is there a way to do this? I'm using this package FYI:

<PackageReference Include="Asp.Versioning.Mvc.ApiExplorer" Version="8.1.0" />

[commonsensesoftware]

ErrorResponses was supplanted by the ASP.NET formal support of RFC 7807 (aka Problem Details). I believe it's been this way since the 6.0 release. The Error Responses topic provides a lot of details about the error responses and how to customize them.

Note that you are versioning by URL segment, which is not RESTful (it violates the Uniform Interface constraint). One of the many consequences of this approach is that it is not always possible to return an error response. This limitation is due to how the ASP.NET routing system works. Since the version value is part of the path itself, there isn't an easy way for the routing system to reason about whether that particular path doesn't exist or whether it's just the an unsupported version. At the point in routing where this happens, the routing system is trying to match a path to the incoming request. Since there isn't a matched path yet, it isn't easy to determine if the route could match.

In earlier versions of the library (<= 5.x), this was done a different way, which could more easily do this; however, it came with performance penalties and resulted in other edge case issues such as not honoring 406 or 415. In addition, a number of folks that version by URL segment want or even prefer 404 in these scenarios. This eventually became a configurable setting via UnsupportedApiVersionStatusCode, which defaults to 400. This doesn't really make sense or apply to URL segment versioning because the path really doesn't exist, not even to the routing system. A path really might not exist, which should return 404. If it cannot be determined that it's not related to versioning, then no additional information can be provided.

This is the only method of versioning that has this problem and limitation. All other versioning approaches have a stable URL path across versions, which means it's easy to collate candidates and determine whether they match the incoming request. If any endpoints can match, then you'll get an appropriate error response; otherwise, it will simply be 404 which is the same behavior if the route really doesn't exist.