I seem as slightly different beasts, with different purposes though there’s some overlap. Primarily, JSON:API may return both content and errors at the same time, it’s not an either/or proposition. This can be quite useful with collections, for example, where some things succeeded, and other things failed. These types can also be used together, for example I’ve used problem details for catch all error handlers, so if one resource starts throwing unhandled errors we still get structured data instead of some random 500 status page that tells me nothing, while using JSON:API to let the resources communicate errors that are perhaps less unexpected (e.g. validation errors.)
It’d be nice though if JSON:API just referred to problem details and added extensions for the JSON:API specific bits.
It’d be nice though if JSON:API just referred to problem details and added extensions for the JSON:API specific bits.