Convention based OpenApi schema generation

[marcwittke]

I am getting tired from adding the same [ProducesResponseType] attribute on my WebAPI controller methods over and over, and I thought there must be an easier, convention based way. I mean, the method clearly tells the return type:

[HttpGet]
[ProducesResponseType<UserSummary[]>(StatusCodes.Status200OK)]
public Task<UserSummary[]> GetAllUsers()
{
    return ExecuteAsync(new AllUserSummariesQuery());
}

My first try turned out pretty straight forward by writing an operation processor:

public class OpenApiResponseTypeConvention : IOperationProcessor
{
    public bool Process(OperationProcessorContext context)
    {
        var method = context.MethodInfo;
        var returnType = method.ReturnType;

        if (returnType.IsGenericType && returnType.GetGenericTypeDefinition() == typeof(Task<>))
        {
            returnType = returnType.GetGenericArguments()[0];
        }

        if (!returnType.IsGenericType && returnType == typeof(Task))
        {
            returnType = typeof(void);
        }

        if (returnType == typeof(void))
        {
            context.OperationDescription.Operation.Responses["204"] = new OpenApiResponse();
        }
        else
        {
            var responseDescription = new OperationResponseDescription("200", returnType, false, string.Empty);
            var schema = context.SchemaGenerator.Generate(returnType, context.SchemaResolver);

            context.OperationDescription.Operation.Responses[responseDescription.StatusCode] = new OpenApiResponse
            {
                Content = { ["application/json"] = new OpenApiMediaType { Schema = schema } },
            };
        }

        return true;
    }
}

The convention is

• return HTTP 204 NoContent when the return type is void (or just a Task)
• return HTTP 200 Ok when the return type is a specific type (or a Task of a specific type) and derive the schema from the CLR's response type

However, this looks way too easy while being too useful for something that hasn't been done before. I am wondering why this one isn't part of NSwag and if I am missing something very important here.