I think JSON [tree] data [with no fixed field for unique identifier, and no fkey referencing] is wrong. The lack of a proper type system+schema for data is wrong. The need for server-side query management makes any API supremely rigid.
Still some concerns to solve, for me, with REST APIs.
JSON covers syntax not semantics. This means you can build the formats you want on top of JSON by only describing the semantics without having to make decisions about syntax or write parsers.
Not taking care of the semantics and letting [mostly] code take care of it is what I don’t like about that format.
[standardization of @id and @type special attributes by JSON-LD sound like a good step forward, imho]
My point is that there’s no point in complaining that a JSON API doesn’t have any particular semantics like the ones you want. If an API says that the format it returns is “JSON”, then what it actually means is that it’s some ad hoc format cooked up on the spot that uses JSON syntax. The problem is not that JSON doesn’t include semantics – that’s out of scope for JSON – the problem is that the API in question half-assed its format design.
> standardization of @id and @type special attributes by JSON-LD sound like a good step forward
But those were standardised. In the JSON-LD spec.
If you want a format that has specified semantics, use a format that has specified semantics. Like JSON-LD. JSON only solves the syntax part of the problem, by design. It’s not there to define semantics, that’s what formats built on top of JSON do.
Still some concerns to solve, for me, with REST APIs.