Skip to content
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

Closed
jimmcslim opened this issue Jun 16, 2020 · 6 comments
Closed

Support for RFC 7807 #528

jimmcslim opened this issue Jun 16, 2020 · 6 comments

Comments

@jimmcslim
Copy link

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
Copy link
Owner

tmenier commented Jun 16, 2020

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
Copy link
Author

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
Copy link

@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
Copy link
Owner

tmenier commented Jul 23, 2020

@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
Copy link

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
Copy link
Owner

tmenier commented Sep 12, 2020

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.

@tmenier tmenier closed this as completed Sep 12, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants