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

> I'll send a link to this to apps-discuss for their info.

OK, thanks :). Hi apps-discuss, and thanks for your willingness to come engage in our issue tracker.

> Well, it's a SHOULD, so you can violate it if you have reason to. It's a requirement because it seemed important to document the error type, but I agree that it might be too high a bar -- it's more of a strong suggestion than a requirement.
>
> I'm happy to downgrade it to something more suggestive.
>
> BTW, just to be clear, you're not saying it's a problem that it's a URI (possibly relative), correct?

I think the core of my issue is envisioning someone designing a HTTP API, perhaps someone who hasn't bought into REST all that much. They might naively expect something like `{ "type": "not_enough_money" }`. Being told that they have to convert this to `{ "type": "https://api.example.com/error-types/not_enough_money" }` could cause them to abandon this spec on first read-through as not suited for their server. If they could simply do `{ "type": "not_enough_money" }`, that would be great. If they instead had to do `{ "type": "about:not_enough_money" }` or something, that might also be OK. Remember that we don't need to be globally unique here---we just need to be unique per-API.

What are your thoughts on this perspective? When you talk about possibly-relative URLs, do you mean that `{ "type": "not_enough_money" }` is fine, since technically it fits the grammar of a relative URL?

> "title" is defined by the error type, and therefore static between instances of the error. "detail" is specific to a particular instance.

Sure, I got that. But when is that _helpful_?

> I think the mapping is:

OK, this is a bit worrying. So given `new TypeError("custom ID must be a string")`, your mapping is:

```
"type": "TypeError"
"title": "Type Error"
"detail": "<...gory stack details here ...>"
```

So there isn't even any place for `message` to go?

> For example, you might use it to correlate a particular instance of an error in logs, identify it in support calls, etc.

> Make sense, or need more convincing?

Makes sense indeed. Error logs is a good point to bring up. Although, again, suggesting that it should be a URL seems unlikely to be something that people will be willing to do. A simple ID would be something I could envision actually implementing. Whereas, I'm definitely not going to spin up the HTML page production machinery (templating, etc.), in order to write out a new page and start serving it, in the middle of my error handler. A GUID or incrementing "problemID" seems more likely what I would program into my server.

> I like the sound of that. Any preference in terms of style?

Sub-object would be my weak preference. @slightlyoff might have more opinions.

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