Add Description to ProducesResponseType (and others) for better OpenAPI documents #55656
Labels
api-suggestion
Early API idea and discussion, it is NOT ready for implementation
area-minimal
Includes minimal APIs, endpoint filters, parameter binding, request delegate generator etc
area-mvc
Includes: MVC, Actions and Controllers, Localization, CORS, most templates
Background and Motivation
The purpose of this API Change is to make it easier for developers to add the
Description
properties to their OpenAPI documents using the[ProducesResponseType], [Produces] and [ProducesDefaultResponseType]
attributes in controller actions.Developers currently use these properties to enrich the OpenAPI document of the API. It tells the reader the possible return values from an endpoint, like a status code, response model type and content type:
See code + OpenAPI example
OpenAPI document is generated using NSwag (I used a JSON to YAML converter)
However, there is currently no way to map OpenAPIs
description
using attributes, which is the easiest way to enrich your methods with OpenAPI information which also works well with the OpenAPI analyzers.It's important to make it easy for developers to set up the
Description
property because this adds a lot of important information to a specific response. For example, if an API returnsHTTP 422
, it would be useful to add a description explaining why/when this error is returned. Without this, handling this error in the client becomes more difficult because the meaning is lost.There are other ways to set the
Description
right now, but I'm not a big fan of them. I explain why in Alternative designs below.I've wanted this feature in ASP.NET Core for a while. I've created this API proposal after talking to @captainsafia about this at the MVP Summit 2024, and she agreed that this would be a worthy addition. I had already created #54064 for this at some point. I hope the rest of the team/community agrees!
Proposed API
This list might be incomplete. I would welcome help finding the impact this has in other files. For more detailed changes, see my ongoing work.
The
Description
would be added toIApiResponseMetadataProvider
which is implemented by[Produces], [ProducesDefaultResponseType] and [ProducesResponseType]
:I've chosen to only highlight the diff of
ProducesResponseType
here to keep this proposal brief.Let me know if you want me to highlight other impacted files like the other attributes.
It might also impact other files, like
ApiResponseType
:Usage Examples
Alternative Designs
XML comments
An alternative design is to do nothing and use the built-in solution, which are XML comments:
This will fill the
description
properties with the values from the<response>
tags.However:
[ProducesResponseType]
(and the other ones mentioned above) and XML comments.<response>
can set a description for[ProducesDefaultResponseType]
To summarize: I do not think that XML comments is the correct one.
Library specific attributes
Both Swashbuckle.AspNetCore and NSwag have their own versions of
[ProducesResponseType]
called[SwaggerResponse]
that do support the OpenAPIDescription
property.However, there are several downsides to this:
[ProducesResponseType]
is library agnostic. By using[ProducesResponseType]
I could switch from Swashbuckle to NSwag and the OpenAPI document generation should keep working, which isn't guaranteed if I used a library specific attribute.[SwaggerResponse]
with[ProducesResponseType]
to set up response descriptions doesn't work. When[SwaggerResponse]
is used, all instances of[ProducesResponseType]
are ignored for that method.[SwaggerResponse]
for description support and others can still use[ProducesResponseType]
, which makes things more difficult to read because their method signature is different.[SwaggerResponse]
, which means I need to disable those warnings for specific methods, which is annoying and makes code more difficult to read.If ASP.NET Core's
[ProducesResponseType]
would support things like Description, the library-specific versions attributes might not be needed anymore, which makes it even easier to switch libraries in the future.Risks
Swashbuckle.AspNetCore's SwaggerResponse
[ProducesResponseType]
and already has its own Description property, which means that this change might cause some issues for them. However, .NET 9 won't ship Swashbuckle anymore by default, reducing the impact this has. Regardless, Swashbuckle's authors should be informed of this change.The text was updated successfully, but these errors were encountered: