Should Content-Type "application/problem+json" be considered a (sub) subtype of "application/json" in terms of the Accept header?

I am building API endpoints that will deliver error responses as mime/media type application/problem+json (see RFC 7807).

So something like this (example from [1]):

HTTP/1.1 401 Unauthorized
Content-Type: application/problem+json; charset=utf-8
Date: Wed, 07 Aug 2019 10:10:06 GMT
{
    "type": "https://example.com/probs/cant-view-account-details",
    "title": "Not authorized to view account details",
    "status": 401,
    "detail": "Only users with the role administrator are allowed to do this.",
    "instance": "/account/123456/details"
}

My question is, could application/problem+json be considered a (sub)subtype of application/json in terms of acceptable response media types? I.e. if a request's Accept header specifies application/json but not application/problem+json, would it be valid to deliver a application/problem+json response?

Encoding considerations and Fragment identifier considerations are explicitly the same as for application/json (not that that would mean a whole lot). I've also come along the statement

"Content-types that end with +json are basically treated as application/json."

but not in official documentation.

One could argue that, syntactically, any problem+json content would also be valid json content. So, by that rationale, accepting the latter could be seen as implying also accepting the former by extension.

On the other hand, I tend to read RFC 7231 as subtypes being by their grammar tokens that do not and can not express a hierarchy. The wording in same RFC concerning the Accept header suggests that it explicitly specifies the response media types that are acceptable, rather than any type that would also match the content.

So I am unsure.

Can/should a proper API respond with application/problem+json type responses to requests with only application/json in the Accept header field?

One could argue that, syntactically, any problem+json content would also be valid json content. So, by that rationale, accepting the latter could be seen as implying also accepting the former by extension.

No, +json types are not "subtypes" of application/json. I understand the rationale. application/json only says something about the syntax, not the format, and +json (and +xml) types say something about both the format and the syntax.

In other words, whilst we can assume that an Accept including application/json will be able to parse the problem JSON response, we cannot assume it will be able to process it.

I.e. if a request's Accept header specifies application/json but not application/problem+json, would it be valid to deliver a application/problem+json response?

It depends on if you want to content-negotiate or not. It is acceptable to not content-negotiate when an error is encountered. Serving Content-Type of x ignoring Accept is fine. You are not negotiating any content-type, but interpreting y to mean x is not intended (or valid in terms of Content Negotiation).

The appropriate thing to do is to serve a 406 Not Acceptable (or 415 Unsupported Media Type, when you have the same question for processing a request body), and we can help the user by being really helpful. For example, when a user-agent sends our apis application/json (among other things), we will show a HTML page with:

Please choose one of the following types:

This endpoint tried really hard to show you the information you requested. Unfortunately you specified in your Accept header that you only wanted to see the following types: application/json.

Please add one of the following types to your Accept header to see the content or error message:

---

1. application/vnd.delftsolutions.endpoint_description.v1+json

2. text/vnd.delftsolutions.docs

3. */*

4. text/*

5. text/html

6. application/vnd.opus-safety.site.v1+json

7. application/vnd.opus-safety.site.v2+json

8. application/vnd.opus-safety.site.v3+json

9. image/svg+xml

10. image/*

---

In case of an error, application/problem+json will be in this list, which is automatically rendered.

We tell our API consumers to interpret the Content-Type to be able to extract the error message.

So I am unsure.

In general, when you're following standards and you are uncertain, doing what's most "helpful" to you can often be the best choice. In this particular case, responding with a problem when someone is requesting json will likely make it harder to debug logs, so I wouldn't recommend it!