I will say that we probably didn't do as much initial homework into the competing standards, as generally picking an accessible enough, flexible enough spec for

I will say that we probably didn't do as much initial homework into the competing standards, as generally picking an accessible enough, flexible enough spec for everyone to know religiously was much more important than the particular one we chose. So we didn't do as much initial vetting of hyperschema and friends once we understood JSONAPI well enough. Meta is an extraordinarily nice escape hatch that we have used as we have learned good patterns that scale when adopting the spec across the business. It is very nice for calculated values, and really lets you have a grab bag of "stuff that isn't quite CRUD" or expensive to calculate values that may want to be contextualized somehow. Though it can be modeled as CRUD depending on the business case, our experience is that some stuff just doesn't belong on another resource but feels awkward as an attribute. However, since the JSONAPI backend has matured we have sought ways to describe and document the resources and their interactions for both backend and front end tooling, automated and otherwise. What we've found is that Swagger and friends (I will return to your hyperschema question shortly) are good when your resources are nonstandard and the CRUD interactions are complex. When your spec (in our case JSONAPI) dictates the CRUD behavior explicitly, the only moving parts are the resources themselves. But in order to get buyin from that tooling, you must enumerate all the various CRUD routes. When you have users, posts and comments, we might have the following routes: GET /users GET /users/id POST /users PATCH /users/id DELETE /users/id GET /users/id/comments GET /users/id/relationships/comments POST /users/id/relationships/comments DELETE /users/id/relationships/comments GET /users/id/posts GET /users/id/relationships/posts POST /users/id/relationships/posts DELETE /users/id/relationships/posts That's just from the user side. Imagine as we add more of these connections, and potentially want to have users_v1 and users_v2, and maybe we add 10-15 extra resources and their admin counterparts. All those routes are boring and noninteresting. The important part is the resource itself, but Swagger and Hyperschema seemed to make us want to specify all those combinatorially large number of possible routes and describe the resources themselves to fullest detail. That's annoying and I'd rather describe my few dozen resources well, and just make the JSONAPI spec homework for devs to read for learning how the legos fit together. From there tooling can be written on client and server to assert consistent behavior by funneling resource definitions through and producing payloads / validation to keep your server in check. With sufficiently documenting tooling, the CRUD routes are entirely bookkeeping and can be abstracted away into your framework We have a single `create` function in our backend for all our resources, for example, and it just asks the resources about themselves to figure out how to do its mechanics. I think we could generate json:ld if we needed to. Our internal DSL allows us flexibility to spit out JSON Schema validation on the fly, so no reason we wouldn't also do that with some tweaks. My twitter is in my profile. Shoot me a message there if you have some deeper questions, though I'm more than happy to try and answer here.