New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

`additionalProperties: false` in JSON Schema #851

Closed
ethanresnick opened this Issue Aug 23, 2015 · 2 comments

Comments

Projects
None yet
2 participants
@ethanresnick
Member

ethanresnick commented Aug 23, 2015

The JSON Schema we host now at jsonapi.org currently says that additional properties are not allowed in any spec-defined objects, which is correct:

"Unless otherwise noted, objects defined by this specification MUST NOT contain any additional members."

However, the spec also says that, if clients and servers do encounter any additional properties, they must ignore them, which allows us to extend the base objects in the future.

I'm worried that some server devs will use the current schema to validate incoming request documents, and then (inadvertently) their servers will inadvertently reject documents by future clients (i.e. with extra properties) that they should accept.

So, I see a few options:

  1. We could change the schema to say additionalProperties: true. This removes the risk of servers/clients rejecting valid documents because they check them against our schema, but it also makes the schema slightly less useful for clients/servers to use in their test suites to check that they're always producing valid documents.
  2. We could add a prominent note (which some will nevertheless overlook) saying that, while it's fine to use this schema to validate documents your code is producing, you shouldn't use it to validate incoming documents.
  3. We could create two schema versions, one for the test suite case and one for incoming document validation...but that seems like a lot to maintain.
@bf4

This comment has been minimized.

Show comment
Hide comment
@bf4

bf4 Aug 23, 2015

Contributor

All good points. Maybe the can be addressed by naming, having 'the schema' aka spec validation version and a 'production' version (I hesitate to say strict and transitional).

I don't know json_schema well enough if such a thing is supported within it and lazy me not looking right now :)

Some erb-type doc generator could allow two versions from one source for sure.

Contributor

bf4 commented Aug 23, 2015

All good points. Maybe the can be addressed by naming, having 'the schema' aka spec validation version and a 'production' version (I hesitate to say strict and transitional).

I don't know json_schema well enough if such a thing is supported within it and lazy me not looking right now :)

Some erb-type doc generator could allow two versions from one source for sure.

ethanresnick added a commit to ethanresnick/json-api-1 that referenced this issue Sep 13, 2015

ethanresnick added a commit to ethanresnick/json-api-1 that referenced this issue Sep 13, 2015

ethanresnick added a commit to ethanresnick/json-api-1 that referenced this issue Sep 13, 2015

ethanresnick added a commit to ethanresnick/json-api-1 that referenced this issue Sep 13, 2015

@ethanresnick

This comment has been minimized.

Show comment
Hide comment
@ethanresnick

ethanresnick Sep 14, 2015

Member

Closing in favor of #867

Member

ethanresnick commented Sep 14, 2015

Closing in favor of #867

sebilasse pushed a commit to redaktor/json-api that referenced this issue Sep 14, 2015

redaktor
added JSON schemas 🔍
please see / should fix
json-api#867
json-api#851

partially fixes
json-api#406
---> see my following answer in
json-api#867 regarding versioning
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment