-
-
Notifications
You must be signed in to change notification settings - Fork 390
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for RFC 7807 #528
Comments
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. |
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. |
@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? |
@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. |
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. |
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. |
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?
The text was updated successfully, but these errors were encountered: