Rough in a Problem HTTP field

[mnot]

A couple of decision points to note:

• This mandates that title and detail contain ASCII strings. If folks feel unicode support is important, that could be done by also allowing binary, or using some encoding.

• This requires the problem type to define the SH type of any extensions. They also could be inferred, I suppose - but if there's any JSON structure, that'd get tricky.

For #35.

[mnot]

Yes - my thinking is that an API will define which it uses.

[dret]

On 2022-03-25 02:25, Mark Nottingham wrote:

Yes - my thinking is that an API will define which it uses.

yes, that works well from the perspective of API producers: they choose which way to go and then implement things accordingly.

it's less great from the perspective of consumers who oftentimes will consume more than one API to get their jobs done. now they need to jump back and forth and know what to expect based on which API they're interacting with.

in my mind, the more we can avoid consumers having to "know the API" and allow them to just work seamlessly across resources, the better. which is why i think even though it certainly is feasible to also represent problem details in a header field, it may be the better design overall to avoid adding the requirement to know where to look for problem details.