search

tmenier / Flurl

Fluent URL builder and testable HTTP client for .NET
https://flurl.dev
MIT License
4.18k stars 385 forks source link

Support for RFC 7807 #528

Closed jimmcslim closed 4 years ago

jimmcslim commented 4 years ago

Is there any plan for support of RFC 7807: Problem Details for HTTP APIs

https://tools.ietf.org/html/rfc7807

Or is there any guidance around sample implementation?

tmenier commented 4 years ago

Admittedly I've never heard of this. Generally though, I've shied away from making specific JSON payload objects first-class members of the library. I've been tempted with OAuth2 request/response bodies, and I think we can agree those are far more widely used than Problem Details.

The guidance for now is to just create a C# class matching the problem details format and follow the try-catch pattern for error handling.

I can keep this open for now in case interest in it grows, but since it's not a very widely used thing and there's an easy way to it without first-class support, it's unlikely this will make it into the library anytime soon.

jimmcslim commented 4 years ago

Fair enough. ASP.NET Core has built-in support for returning errors in this format, so it may start to come up a bit more frequently.

https://docs.microsoft.com/en-us/aspnet/core/web-api/handle-errors?view=aspnetcore-3.1#exception-handler

eldonferranpol commented 4 years ago

@tmenier I think it definitely makes sense that Flurl doesn't get too much into the specifics of Json. We use a tiny Json Client sat on top of flurl. It is based on some of our own Api conventions, including use of application/problem+json.

https://github.com/sensemaking/core/tree/master/Http.Json.Client

Would you have any interest in a pull request putting together a Flurl.Http.Json.Client as a separate package outside of Flurl.Http broadly similar to, but dealing with more generalised cases than, the one above?

tmenier commented 4 years ago

@eldonferranpol So you are talking about a separate library with a dependency on Flurl.Http? Sounds like something you could maintain in a separate repo, no? I'm just not sure where a PR to me would come into play.

eldonferranpol commented 4 years ago

Yes apologies scrap that completely. Talking rubbish. To be honest I have been using my own layer over the top that tweaks bits and bobs for things like Siren and Problems for so long that I had completely forgotten how much Json/serialisation etc. support is in Flurl.Http.

tmenier commented 4 years ago

Cleaning up my backlog a bit and decided to close this. I think it's unlikely that I'll change my mind on it, given my reasoning above. If I'm wrong, we can always reopen it.