Closed nhwilly closed 2 months ago
@nhwilly is this still an issue or has it been resolved by #177 and other 9.0.x updates?
Traveling overseas. Won't get a hard look at it until end of the month. Thanks to everyone for the work and attention.
Now that I've had a moment to try it out...
This works great when I'm using it to return Created
from methods, etc. So, thanks very much for that improvement.
It carries a Location
property, but when using the extension method ToMinimalApiResult
the Location
property is set to an empty string.
I understand the limitation. Certainly in the case of FastEndpoints
, they are using the class type of the endpoint that will return the GET
value, which probably won't be available from deeper in the system.
In the end, in FastEndpoints
we still need to check on a Created
result and build the location there.
I think this does all it can do at the moment.
Thanks for putting this in.
Extension methods exist that allow for a derived version of a FastEndpoints endpoint to be used to simply return a
Result<T>
. It also extends the invalid request behavior by transformingIEnumerable<ValidationError>
to aProblemDetails
.This works well, but falls short in a couple of ways. I believe this could become a go-to approach for endpoints with some small enhancements.
Extend
Result.Status
enum to include aCreated
value.This would allow the derived endpoint to distinguish between a
Result.Ok
of 200 and aResult.Created
of 201.The challenge: Allowing for the derived endpoints to create a
CreatedAt
response that includes the route to the new resource. This normally includes a route and at least anid
value.My current endpoint code looks like this:
So creating
Result.Created<T>(T value)
would look just exactly likeResult.Success<T>
.But there would also have to be a
Result.CreatedAt<T>(T? value, object id, string route)
Or something like that. Not sure how FastEndpoints does it or how I would create a generic approach.
Conversion of
IEnumerable<ValidationError>
toProblemDetails
NOTE: This is
Microsoft.AspNetCore.Mvc.ProblemDetails
This can be done, but FastEndpoints relies on Fluent Validation's
ValidationFailure
which has more details about the problem. This means thatFluentValidation
errors that occur in command handlers and queries lose that detail when they are returned upstream usingResult.Invalid
.Adding a way to pass up the equivalent of a
ValidationFailure
usingResult.Invalid
or some other status code would allow the details to be retained and ultimately properly converted to aProblemDetails
by FastEndpoints (or anything else).I had done some work on this before I retreated to the standard
Ardalis.Result
package. (This is from LinqPad). That code is below if it helps anyone.These are suggestions. I am moving forward with what's working now, and for the record, I did not use a derived class from FastEndpoints, waiting for a more complete solution.