Closed maricn closed 1 year ago
RFC-6838 defines "Structured Syntax Name Suffixes", and in particular it defines that anything with a +json
suffix should be treated as application/json
unless there are stricter rules for that exact media type.
As such, it seems reasonable (to me at least, and I'm not an expert!) to reply with application/problem+json
to something that only accepts application/json
- since, per those rules, application/problem+json
can be interpreted as valid application/json
as well.
@sazzer thank you for the prompt response - i find that logic very reasonable!
it is also implicit in the examples i linked in the original post, but considering how the RFC at hand defines application/problem+json
, i would personally still find it valuable if that piece of "sidenote" information would be explicit in the document..
Personally, I agree, and I think that having the examples be inconsistent isn't great. I was just explaining how they are both technically valid :)
(1) is saying that the client expects json (in the case of a successful response), and also can process the problem format.
(2) is a request, not a response.
In some examples ([1] and [2]) at current state of
main
branch, there are different values of theAccept
request header -application/json
andapplication/json, application/problem+json
. They are interchangeably used without any comment or note. This creates confusion and it could be helpful to have a clarification of how does the Accept header influence the response.