Skip to content

RFC9110 - UnprocessableContent #42302

@khellang

Description

@khellang

Background and Motivation

Now that RFC 9110 - HTTP Semantics is official, with the inclusion of the 422 Unprocessable Content status code, I'd like to propose the following changes to ASP.NET Core APIs.

Existing (shipped) members containing UnprocessableEntity is kept, but will simply forward to its UnprocessableContent counterpart.

Proposed API

namespace Microsoft.AspNetCore.Http;

public static class StatusCodes
{
+    public const int Status422UnprocessableContent = 422;
}

public static partial class Results
{
+    public static IResult UnprocessableContent(object? error = null) { throw null; }
}

public static class TypedResults {
-    public static UnprocessableEntity UnprocessableEntity();
+    public static UnprocessableContent UnprocessableContent();
-    public static UnprocessableEntity<TValue> UnprocessableEntity<TValue>(TValue? error) { throw null; }
+    public static UnprocessableContent<TValue> UnprocessableContent<TValue>(TValue? error) { throw null; }
}

namespace Microsoft.AspNetCore.Http.HttpResults;

-public sealed class UnprocessableEntity : IResult, IEndpointMetadataProvider { }
+public sealed class UnprocessableContent : IResult, IEndpointMetadataProvider { }

-public sealed class UnprocessableEntity<TValue> : IResult, IEndpointMetadataProvider { }
+public sealed class UnprocessableContent<TValue> : IResult, IEndpointMetadataProvider { }

Alternative Designs

Keeping the old name as-is? Should the existing UnprocessableEntity APIs be marked as [Obsolete]?

Risks

I'm not sure there are any.

Metadata

Metadata

Assignees

No one assigned

    Labels

    api-suggestionEarly API idea and discussion, it is NOT ready for implementationarea-minimalIncludes minimal APIs, endpoint filters, parameter binding, request delegate generator etc

    Type

    No type

    Projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions