Provide the ability to return status codes other than 400 when responding to a request for an unsupported version about aspnet-api-versioning HOT 2 CLOSED

I was hestitant to even include this capability at all, but ultimately:

1. There was a benefit to having a factory for creating error responses. I chose a delegate over an interface.
2. Service authors might want to change the error payload.

It was never anticipated that a service author would return anything other than HTTP status code 400 (Bad Request) for an unsupported API version. I would say that returning success for a failed request with a message body that must be interpretted as an error is a violation of the REST constraints. That is the type of service communication we often observed with services that used SOAP over HTTP. Nevertheless, if you'd like to return HTTP status code 200 (OK) for an unsupported API version, it is possible without any design changes.

There isn't anything special about the BadRequestObjectResult. Selecting it as the return type was meant to drive developers toward the proverbial Pit of Success. There are at least 3 simple ways I can think of to meet your requirement:

1. Subclass BadRequestObjectResult, change the StatusCode property to 200 (OK), and then return your custom object result in the ApiVersioningOptions.CreateBadRequest delegate.
2. Intercept the default ApiVersioningOptions.CreateBadRequest delegate and just change the StatusCode of the original result.
3. Define a custom method for ApiVersioningOptions.CreateBadRequest that uses whatever content you want and changes the StatusCode to 200 (OK) before returning the result.

The following is an example of option 2, which is probably the easiest to implement:

using Microsoft.AspNetCore.Http;

services.AddApiVersioning( options =>
{
    var newBadRequest = options.CreateBadRequest;
    options.CreateBadRequest = ( request, code, message, messageDetail ) =>
    {
        var result = newBadRequest( request, code, message, messageDetail );
        result.StatusCode = StatusCodes.Status200OK;
        return result;
    };
} );

There are 3 scenarios and error codes where this method will be called:

You may find this information useful in deciding how you craft your custom responses.

from aspnet-api-versioning.

@commonsensesoftware - many thanks for the swift and detailed response. Option 2 will work fine for our purposes. I understand your arguments about how RESTful our approach is. This is still under review (and in this case the choice between 400 and 200 is not clear cut). However, our aim is to offer the simplest solution for our likely api consumers (many of whom will not be web developers with a familiarity of REST and HTTP).

from aspnet-api-versioning.