Re: [spec-reviews] http-problem (#37)

Yeah, we're starting to get at the source of the issue here. Which is that, I think most programming languages don't encourage you to create an entirely new error class for each situation. Instead, you reuse a few error types (e.g. ArgumentException or TypeError or similar) in many different ways.

The larger point I'm arguing is to think about how server-side programers are meant to be using this and integrating it with their existing programming paradigms, most of which will be based around things like `new TypeError("customerID field must be a string")` (JavaScript) or `new ArgumentException("customer ID must be a string of alphanumeric characters")` (Java). If this draft were written by one of them, I think they would have likely reduced to either one or two fields (message, and maybe type).

As-is, there's a pretty big mismatch between the error model implied by this draft, and the one I think most server-side software will be using already. So the implication is that server-side programmers will not be able to start producing these problem responses right away, until they go through all of the places in their current system that produce errors, and replace those lines of code with something that produces an appropriate `{ "type", "title", "detail" }` structure. If this is the path envisioned, that's fine---maybe someone will publish an npm package that lets you do `throw new Problem({ type, title, detail })` and people will start using that instead of `throw new TypeError`. Or maybe the next version of Rails/Spring/etc. will define similar classes built-in to their response processing. But that's a very different adoption path than would be given by a single `"message"` field, and implies a lot more work on the part of both framework authors and server-side deve
 lopers, 
 which I think will limit adoption.

---
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/spec-reviews/issues/37#issuecomment-85242032