@bf4 FYI I've recently done something similar in which I used the jsonapi schema to create a RAML 1.0 type library (JSON->YAML->RAML). I made a resource_post which allows the 'id' to be optional and then resource extends resource_post to make 'id' required.

I also found I had to do a similar thing for my "user" data types that extend resource, making mytype_patch which allows all attributes to be optional (for PATCHing) which is then extended by mytype_post (for POSTing) which identifies the required attributes and then mytype (for GETting) which extends the post to require the 'id'. Still not quite correct and not completely DRY.

Oh, and from another thread, the info response type goes with the DELETE 200 response:

200 OK

A server MUST return a 200 OK status code if a deletion request is successful and the server responds with only top-level meta data.

I wish I had seen this work before reinventing it! Oh well.

Incidentally, I think the schema naming of success/failure/info is a little misleading.

  "oneOf": [
    {
      "$ref": "#/definitions/success"
    },
    {
      "$ref": "#/definitions/failure"
    },
    {
      "$ref": "#/definitions/info"
    }
  ],

• a success schema has data and optionally meta, links, included, jsonapi
• a failure schema has errors and optionally meta, jsonapi,(unclear if links is allowed)
• an info schema has meta and optionally links, jsonapi

Why not just call them data, errors, meta?

I would need a schema for "create". Too bad there hasn't happened anything here in a while.

@dgeb I started to break them up, but my current requirements and timelines don't allow me to complete that right now.
Is this something you're interested in?
I also note, the schema only validates responses, and separate schemas would be required to validate requests.

I'm going to close this in favor of #1600. I hope that we can merge #1600 soon.

Thanks a lot @bf4 for starting the work!