Add TypedResults static factory class for creating typed IResult objects

[DamianEdwards]

• Reinstate the HttpResult suffix on IResult types except for where the short name has recognized value, e.g. those types that implement IEndpointMetadataProvider and will be used in conjunction with Results<T1, TN>, e.g. Results<Ok<Todo>, NotFound>
• Change from Results.Typed.xxx to TypedResults.xxx
• Added HttpResults.ValidationProblem type that represents 400 responses with validation errors (equiv to BadRequest<HttpValidationProblemDetails>
• Changed TypedResults.ValidationProblem to return new HttpResults.ValidationProblem type
• Moved Results<TResult1, TResultN> types into the Microsoft.AspNetCore.Http.HttpResults namespace to match where the other results types are
• Changed Results.xxx methods to call through to TypedResults.xxx methods
• Explicitly implemented IEndpointMetadataProvider on following IResult types:
  • Accepted
  • Accepted<TValue>
  • AcceptedAtRoute
  • AcceptedAtRoute<TValue>
  • BadRequest
  • BadRequest<TValue>
  • Conflict
  • Conflict<TValue>
  • Created
  • Created<TValue>
  • CreatedAtRoute
  • CreatedAtRoute<TValue>
  • NoContent
  • NotFound
  • NotFound<TValue>
  • Ok
  • Ok<TValue>
  • UnprocessableEntity
  • UnprocessableEntity<TValue>
• Order using statements before namespace declarations
• Added tests for Microsoft.AspNetCore.Http.Results and Microsoft.AspNetCore.Http.TypedResults

Fixes #41009

[davidfowl]

Here's a bit of a compromise on what I said about conflicts. We change all of the classes to verbs instead of nouns and keep the all without the result/httpresult.

Thoughts?

[DamianEdwards]

Here's a bit of a compromise on what I said about conflicts. We change all of the classes to verbs instead of nouns and keep the all without the result/httpresult.

Example? Like ReturnValidationProblem, ReturnOk?

The other thought that came up last week was keeping the HttpResult suffix and just letting folks use type aliasing (global if they choose) if they want the short names, but that requires closing any generic unfortunately, e.g.:

using OkTodo = Microsoft.AspNetCore.Http.HttpResults.OkHttpResult<Todo>;
using NotFound = Microsoft.AspNetCore.Http.HttpResults.NotFoundHttpResult;

app.MapGet("/todo/{id}", async Task<Results<OkTodo, NotFound>> (int id, TodoDb db) =>
    await db.Todos.FindAsync(id) is Todo todo
        ? new OkTodo(todo)
        : new NotFound();

[brunolins16]

Example? Like ReturnValidationProblem, ReturnOk?

Seems a little bit weird have verbs in the class names and it does not sound better that *HttpResult. I know that might be less clear but what about an alternative name? Eg. Ok -> Succeeded

[DamianEdwards]

Seems a little bit weird have verbs in the class names and do not sound better that *HttpResult. I know that might be less clear but what about an alternative name? Eg. Ok -> Succeeded

Kinda hate it 😄 Sticking with well established names for HTTP statuses is the only logical thing to do I think.

[brunolins16]

Seems a little bit weird have verbs in the class names and do not sound better that *HttpResult. I know that might be less clear but what about an alternative name? Eg. Ok -> Succeeded

Kinda hate it 😄 Sticking with well established names for HTTP statuses is the only logical thing to do I think.

To be honest I hate it as well 😂

[BrennanConroy]

Didn't go over the new APIs with a fine-toothed comb, but I'm assuming they are what we approved.

Thanks for the new tests for the existing types :)

[khellang]

@DamianEdwards Is it too late to rename these to Unprocessable Content to match the new official reason phrase from RFC9110?

[khellang]

My proposal; main...khellang:unprocessable-content

[khellang]

Also filed #42302