Improve Endpoint API BadRequest handling

[987Nabil]

Currently we only return a http 400, if the endpoint API can't decode the request. That is not very helpful to the user/dev. They can't know what exactly went wrong.

Improvement

• Make it possible to return a json or html body (setting or accept header) that let's the caller know what was missing/went wrong
• Make it possible to configure logging of missing request data, that is rendered in a way that is helpful to the developer

[swoogles]

This would be extremely valuable 👍

[jdegoes]

I think we need two changes:

1. If the user does not handle the error explicitly, then we encode an error in a content-type acceptable to the HTTP client, perhaps defaulting to application/json. Moreover, we use a format that is somewhat standardized for returning error details. The main consideration, however, is just making sure that when users don't handle encoding/decoding errors, we do something that helps end-users diagnose and fix their encoding/decoding issues.
2. We need an operator that lifts encoding/decoding errors (currently defects) into E, and we need to document that, show how it's used, and make it common practice to deal with it.

[987Nabil]

@jdegoes sounds good to me. I would still have a variant of that 2. operator that just logs the codec errors in a standard way. Will be helpful in development.

[jdegoes]

All right, so we have:

1. If the user does not handle the error explicitly, then we encode an error in a content-type acceptable to the HTTP client, perhaps defaulting to application/json. Moreover, we use a format that is somewhat standardized for returning error details. The main consideration, however, is just making sure that when users don't handle encoding/decoding errors, we do something that helps end-users diagnose and fix their encoding/decoding issues.
2. We need an operator that lifts encoding/decoding errors (currently defects) into E, and we need to document that, show how it's used, and make it common practice to deal with it.
3. We need another operator that logs the codec errors in a standard way, useful for development.

The operators should be defined probably on Handler all the way up to Routes (including Route).

Make sense & agreed? cc @swoogles @atooni

[jdegoes]

/bounty $250

[algora-pbc]

💎 $250 bounty created by ZIO
🙋 If you start working on this, comment /attempt #2650 along with your implementation plan
👉 To claim this bounty, submit a pull request that includes the text /claim #2650 somewhere in its body
📝 Before proceeding, please make sure you can receive payouts in your country
💵 Payment arrives in your account 2-5 days after the bounty is rewarded
💯 You keep 100% of the bounty award
🙏 Thank you for contributing to zio/zio-http!

👉 Add a bounty • Share on socials

Attempt	Started (GMT+0)	Solution
🟢 @987Nabil	Feb 8, 2024, 4:33:35 PM	#2714
🔴 @feliciien	Feb 15, 2024, 4:46:39 PM	WIP

[987Nabil]

/attempt #2650

Algora profile	Completed bounties	Tech	Active attempts	Options
@987Nabil	27 ZIO bounties + 0 bounties from 0 projects	Scala		Cancel attempt

[algora-pbc]

@987Nabil: Reminder that in 7 days the bounty will become up for grabs, so please submit a pull request before then 🙏

[feliciien]

/attempt #2650

Algora profile	Completed bounties	Tech	Active attempts	Options
@feliciien	4 bounties from 1 project	MDX, Rust, JavaScript & more		Cancel attempt

[algora-pbc]

Note

The user @987Nabil is already attempting to complete issue #2650 and claim the bounty. We recommend checking in on @987Nabil's progress, and potentially collaborating, before starting a new solution.

[algora-pbc]

The bounty is up for grabs! Everyone is welcome to /attempt #2650 🙌

[987Nabil]

/attempt #2650 still on it.

[algora-pbc]

💡 @987Nabil submitted a pull request that claims the bounty. You can visit your bounty board to reward.

[algora-pbc]

🎉🎈 @987Nabil has been awarded $250! 🎈🎊

• Share on socials
• Give feedback