Check HTTP response content type before trying to decode it as JSON

[IsaacG]

No description provided.

[SleeplessByte]

You should check for both this or ends with +json so that Jeremy can switch in the future to a +json type.

E.g.

application/problem+json

[IsaacG]

You should check for both this or ends with +json so that Jeremy can switch in the future to a +json type.

Done. I'm not familiar with that new format. Is the intend that you can put any arbitrary string there? application/<anything>+json?

[SleeplessByte]

Yes, common is making a media type in the vnd. (vendor) tree, e.g.

application/vnd.exercism.submission.v1+json

That could be specced to always give the same format for the JSON, instead of merely the JSON syntax. We may never do this, but it's safe to include, guarantees a JSON-syntaxed response and allows us to later decide.

GraphQL for example also has a specced response in their working draft of the spec. It guarantees not just JSON syntax, but also format.

Similar:

# XLS
application/vnd.ms-excel

# XLSX (open format)
application/vnd.openxmlformats-officedocument.spreadsheetml.sheet

It's vital for HATEOAS (a way of designing HTTP APIs as described in Roy Fieldings thesis), used by some of the big ones. Resource dump with surface level information: Don't be smart and use web standards. Example of implementation of type-checked JSON requests and responses.