Swashbuckle.aspnetcore: [5.0.0-rc4] OpenApiOperation Consumes and Produces

[niemyjski]

Perhaps it would be good to add a compatibility package that gives you better insight to what things moved to even if it throws not implemented exceptions. I have the following simple operation filter that would only say we support Json. I know that produces and consumes became paths (at least that's what I took from the what's new video and I read the release notes) but no idea even looking at the api signature what this would become. Perhaps a wiki or docs updates on common examples on upgrading?

public class MyOperationFilter : IOperationFilter {
        public void Apply(Operation operation, OperationFilterContext context) {
            operation.Consumes.Clear();
            operation.Consumes.Add("application/json");

            operation.Produces.Clear();
            operation.Produces.Add("application/json");
        }
    }

To

 public class MyOperationFilter : IOperationFilter {
        public void Apply(OpenApiOperation operation, OperationFilterContext context) {
            operation.???.Clear();
            operation.???.Add("application/json");

            operation.???.Clear();
            operation.???.Add("application/json");
        }
    }

[niemyjski]

@domaindrivendev Is there any chance you could offer any insight on this?

[niemyjski]

I think I figured it out, I added

    [Consumes("application/json")]
    [Produces("application/json")]

to my base controller and now it only shows that.

[ArtemStepanov]

I have many services with many APIs and controllers, so I wanted to know too how can I handle operation.Consumes with V3. Hope that authors will make some "HOWTO MIGRATE FROM V2 TO V3".

[portal7]

same case, for file upload, all examples around the web refers version 2 rather 5.0.0.0-rc4

[SergNikitinSharpDev]

I have many services with many APIs and controllers, so I wanted to know too how can I handle operation.Consumes with V3. Hope that authors will make some "HOWTO MIGRATE FROM V2 TO V3".

You can try global mvc filter: https://stackoverflow.com/q/59491791/2793919

[Lung314]

@niemyjski

I think I figured it out, I added

    [Consumes("application/json")]
    [Produces("application/json")]

to my base controller and now it only shows that.

I didn't quite understand your solution. I tried a few things based off what you said and got things working on my end. I want to confirm if I got the right idea:

When migrating from Swashbuckle to v5 because of updating dotnet to v3, the Solution to Consume/Produce the desired format is to REMOVE the OperationFilter (if you are only using it for Consumes/Produces) entirely and add the attributes [Consume("InsertFormatHere")] and [Produce("InsertFormatHere")] into the base controller.

Correct me if I am wrong?

[domaindrivendev]

Like most things with Swashbuckle, the optimal approach is to let the _actual_ application behavior drive the documentation. For Swashbuckle, the code is the truth, and so it's pretty dam accurate at describing _actual_ behavior, but not always _intended_ behavior. There's a subtle difference here that's important in the context of Swashbuckle.

In your case, your _intention_ is for your API to only accept/respond with JSON media types. However, (documentation aside) have you done anything with your application config to make that intention a reality - i.e. does your application block requests with different media types?

As pointed out above, you can control this at the controller/action level with the Consumes and Produces attributes and Swashbuckle will honor this accordingly. However, you can also control this at the global level by tweaking configured InputFormatters and OutputFormatters, and again ... Swashbuckle will honor this accordingly. For example, if there's an Xml formatter enabled, you can disable it as follows:

services.AddControllers()
    .AddMvcOptions(c =>
    {
        c.InputFormatters.RemoveType<XmlSerializerInputFormatter>();
        c.OutputFormatters.RemoveType<XmlSerializerOutputFormatter>();
    });

Or, if you wanted to restrict the JSON-specific media types to just "application/json" (i.e. not "text/json"), you could configure the Json formatters as follows:

services.AddControllers()
    .AddMvcOptions(c =>
    {
        var jsonInputFormatter = c.InputFormatters.OfType<SystemTextJsonInputFormatter>().First();
        jsonInputFormatter.SupportedMediaTypes.Remove("text/json");
        jsonInputFormatter.SupportedMediaTypes.Remove("application/*+json");

        var jsonOutputFormatter = c.OutputFormatters.OfType<SystemTextJsonOutputFormatter>().First();
        jsonOutputFormatter.SupportedMediaTypes.Remove("text/json");
        jsonOutputFormatter.SupportedMediaTypes.Remove("application/*+json");
    });

[hasancemcerit]

The global MVC filter, both from AddMvc or AddMvcOptions does not seem to work for .net core 3.1.

[Mys73rion]

I think I figured it out, I added

    [Consumes("application/json")]
    [Produces("application/json")]

to my base controller and now it only shows that.

I had to add the type in produces like:
{Produces("application/json", "application/xml", Type = typeof(FooBar))}
Otherwise, Swashbuckle didn't care about the produces.

Consumes worked fine.

[francoscarpa]

I continue to not understand how I should replace operation.Consumes.Clear() and operation.Produces.Clear(). Can anyone help me?

[niemyjski]

You don't anymore, you just define only the attributes you need on the action or controller level and only those will be populated. I'd be rather selective and only put the attributes for produces on the controller actions that return data and the consumes on those that take it (put/post)

[francoscarpa]

I defined [Consumes("application/json")] and [Produces("application/json")] on a class that derives from ControllerBase. Do I just get rid of those four lines of code then? Here I found a comment where someone suggests to use operation.RequestBody.Content and operation.Responses[].Content.

[niemyjski]

Yes

[domaindrivendev]

@niemyjski - can this be closed?

[Dried09]

Why is it closed while no solution provided? All described here is just a workaround. How is it can be migrated from previous implementation to recent _correctly_?

[domaindrivendev]

The correct approach (not a workaround) is described above https://github.com/domaindrivendev/Swashbuckle.AspNetCore/issues/1296#issuecomment-577831898