Update JSON Schema to be v1.0 compliant #1555
Conversation
These changes fix a number of issues in the schema which make it invalid or incomplete in terms of validating JSON:API response payloads.
|
@guillemcanal thanks for your work in #1487! =] I'd suggest closing #1487 in favour of this PR. |
|
@Relequestual LGTM. By the way, do you plan to create a test suite to validate every examples given in the spec against the JSONSchema ? It may be safer :) |
If someone wants to find a way to extract them from the spec, I'm happy to do the validation test work. Otherwise, I don't have the bandwidth immediatly. |
|
I'll try to make some time this week to double check the schema and then remove the draft status. |
@Relequestual Thank you, much appreciated! |
|
This is a much appreciated contribution. How would you proceed with testing? I personally prefer to split a schema as large as this one, but I have not found a good solution to bundle split schemas into a single file yet. Also, do you plan to submit your tests to the repository? |
|
Sorry it has taken me a little while to get back to you here.
My testing suggestion was related to examples in the specification. If they could be extracted, they could be tested against the schema. What language is up to you. I'd stick to what I know and a library that supports 2019-09 or above. In terms of split files. This schema is actually pretty basic, but I still sometimes split even small schemas into multiple smaller ones. @claudenirmf why would you need to bundle them into a single file? |
|
Realistically I'm not sure I'm going to have time to review this soon. If someone wants to review and approve it, then please do, but I make no assurances here 😅. |
Thanks for your response. You are correct, it is a basic schema. I admit that my memory of the actual schema tricked me (past me did not find JSON Schema very readable to begin with).
Some applications can only handle single file schemas, either because of libraries that cannot handle references, or because you want to deliver the schema as a single file (I'm thinking of |
| {"required": ["relationships"]}, | ||
| {"required": ["links"]}, | ||
| {"required": ["id"]}, | ||
| {"required": ["type"]} |
There was a problem hiding this comment.
would this then allow "id" and "type" as attributes member, would that violate one of the restrictions for fields?
a resource can not have an attribute and relationship with the same name, nor can it have an attribute or relationship named type or id.
| "not": { | ||
| "anyOf": [ | ||
| {"required": ["id"]}, | ||
| {"required": ["type"]} |
There was a problem hiding this comment.
should this be moved up one level instead of removed to satisfy the restriction
a resource can not have an attribute and relationship with the same name, nor can it have an attribute or relationship named type or id.
|
I hope to come back to this at some point soon! =D |
| "type": "string", | ||
| "$comment": "The spec doesn't specify that this MUST be a string, so this could be changed to additionally allow numbers" |
There was a problem hiding this comment.
Should we also allow null values?
|
any progress on this? what aboy v1.1? |
|
Closing in favour of #1600 |
These changes fix a number of issues in the schema which make it invalid or incomplete in terms of validating JSON:API response payloads.
Resolves #1554