Why api returns 200 (ok) if wrong Api version is provided in the call to api

[arvindmaurya37]

below are the version of NuGet is used.

PackageReference Include="Microsoft.AspNetCore.Mvc.Versioning" Version="2.3.0" PackageReference Include="Microsoft.AspNetCore.Mvc.Versioning.ApiExplorer" Version="2.2.0" PackageReference Include="Swashbuckle.AspNetCore" Version="3.0.0"

startup.cs

services.AddApiVersioning(o =>
            {
                o.ReportApiVersions = true;
                o.DefaultApiVersion = new Microsoft.AspNetCore.Mvc.ApiVersion(1, 0);
                o.AssumeDefaultVersionWhenUnspecified = true;
             o.ErrorResponses = new DefaultErrorResponseProvider();
            }); 

DemoTestController.cs

  [ApiVersion("2.0")]
        [ApiController]
        [Route("api/v{version:apiVersion}/[Controller]")]
        public class DemoTest : ControllerBase
        {
            [HttpGet]
            public IActionResult Get()
            {
                return new JsonResult(new { ResourceName = "DemoTestAPIController Version 2" });
            }
        }

for the above controller

http://localhost:53858/api/v2.0/DemoTest (this URL is valid and its response should be 200 and it is working as expected)

but for the below URL, the response should be 400(Forbidden). http://localhost:53858/api/v1.0/DemoTest

http://localhost:53858/api/v3.0/DemoTest

following are the expected responses for the respective api versoinig cases. Error Response

https://github.com/Microsoft/aspnet-api-versioning/wiki/Error-Responses

Tried Till now: I also tried to override the DefaultError Response with MyErrorResponseProvider but the debugger does not hit it at all.

with the help of this #233

Startup.cs

services.AddApiVersioning(o =>
            {
                o.ReportApiVersions = true;
                o.DefaultApiVersion = new Microsoft.AspNetCore.Mvc.ApiVersion(1, 0);
                o.AssumeDefaultVersionWhenUnspecified = true;
             o.ErrorResponses = new MyErrorResponseProvider();
            });

MyErrorResponseProvider

class MyErrorResponseProvider : DefaultErrorResponseProvider
{
// note: in Web API the response type is HttpResponseMessage
public override IActionResult CreateResponse( ErrorResponseContext context )
{
       switch ( context.ErrorCode )
       {
           case "UnsupportedApiVersion":
               context = new ErrorResponseContext(
                   context.Request,
                   context.StatusCode,
                   context.ErrorCode,
                   "My custom error message.",
                   context.MessageDetail );
               break;
       }

       return base.CreateResponse( context );
}
}

[commonsensesoftware]

The AssumeDefaultVersionWhenUnspecified is not doing what you think it does in this context. It is impossible to have an optional segment in the path. Remember that the path, the whole path, is the reosurce identifier. It would be no different that requesting api/orders/{id}/items. There is no way to get to line items without providing an order identifier. When you version this way, the same thing is true (which is why I always recommend people no use this approach - amongst other things).

There may be some more sophisticated methods to make this scenario work, but the two obviously ways are:

• URL rewriting or redirection
• Double-route registration

Double-route registration is the fastest and easiest to configure, but it comes with a maintenance cost if you move the default version around.

[ApiVersion("2.0")]
[ApiController]
[Route("api/[controller]")]
[Route("api/v{version:apiVersion}/[controller]")]
public class DemoTest : ControllerBase
{
  [HttpGet]
  public IActionResult Get(ApiVersion apiVersion) =>
    Ok(new { ResourceName = "DemoTestAPIController Version " + apiVersion.ToString() });
}

Notice that there are now two routes, but one without the API version. When a request is made without the API version in path, the routing system will know how to find the controller and now the behavior of AssumeDefaultVersionWhenUnspecified will kick in. In this case, api/demotest will fail because you have configured the default version to be 1.0, but this controller only supports 2.0. If it supported both, then you'd see api/demotest respond with text indicating you've requested 1.0, even though both requests resolve to the same action.

API versioning does not change how routing works. It only updates how routing matches are resolved; specifically, it disambiguates otherwise duplicate route matches by API version.

I hope that helps clear things up.

[commonsensesoftware]

Did you get this working?

For clarity, this is what will happen based on your current setup:

URL	Response
http://localhost:53858/api/v1.0/DemoTest	400 (UnsupportedApiVersion)
http://localhost:53858/api/v2.0/DemoTest	200 (UnsupportedApiVersion)
http://localhost:53858/api/v3.0/DemoTest	400 (UnsupportedApiVersion)

[arooran]

@commonsensesoftware I have the same issue as @ArvindMaurya1996 mentioned.

Microsoft.AspNetCore.Mvc.Versioning Version="3.0.0" 
Microsoft.AspNetCore.Mvc.Versioning.ApiExplorer Version="3.0.0

in ConfigureServices method

services.AddVersionedApiExplorer(option =>
            {
                option.GroupNameFormat = "'v'VVV";
                option.SubstituteApiVersionInUrl = true;
                option.AssumeDefaultVersionWhenUnspecified = true;
                option.DefaultApiVersion = new ApiVersion(1, 0);
            });
  services.AddMvc().SetCompatibilityVersion(CompatibilityVersion.Version_2_2);

 services.AddApiVersioning(v => {
                v.ReportApiVersions = true;
                v.AssumeDefaultVersionWhenUnspecified = true;
                v.DefaultApiVersion = new ApiVersion(1, 0);
                v.ApiVersionReader = new UrlSegmentApiVersionReader();
                v.ErrorResponses = new MyErrorResponseProvider();
            });

services.AddTransient<IConfigureOptions<SwaggerGenOptions>, ConfigureSwaggerOptions>();
            services.AddSwaggerGen();

in Configure method

  app.UseMvc();
  app.UseApiVersioning();


    [ApiController]
    [ApiVersion("1")]
    [Route("api/v{version:apiVersion}/test")]
   public class TestController : BaseApiController
    {
        [HttpGet]
        public IActionResult Get() {
            return Ok(new
            {
                message = "test controller"
            });
        }
 }

It should return 200 for this URL https://localhost/SampleApp/api/v1/test
but it is still valid (200) for this URLs as well
https://localhost/SampleApp/api/v2/test
https://localhost/SampleApp/api/v3/test

Quite confused about this versioning. Any idea to resolve this issue?

[arvindmaurya37]

For my case services.AddMvc().SetCompatibilityVersion(CompatibilityVersion.Version_2_2); this did the magic.

https://docs.microsoft.com/en-us/aspnet/core/mvc/compatibility-version?view=aspnetcore-2.2
as mention in the above link, we need to set CompatibilityVersion for 2.x versions
and CompatibilityVersion is no more needed in version 3.x

[commonsensesoftware]

@arooran what does BaseApiController look like or do? I used the sample source you provided against and things appear to work for me. I received 400 with UnsupportedApiVersion as expected.

I also noticed that you're using 3.0.0, which is way back to pre ASP.NET Core 2.2. That's been a year or more ago now. Is there some reason why you haven't moved forward to 2.2+? There have been a number of fixes and enhancements since then, but I didn't backport them to 3.0.0. API Versioning 3.1.0+ will have all of those changes. This is a very common scenario so it seems unlikely, but there is a change this could be related to an old bug that has long been fixed, but isn't available in the 3.0.0.

[arooran]

@commonsensesoftware Thanks for your update. I have updated to latest verion 4.0.0 for API versioning. It is working as expected. you can close this issue.