adding a required property is showing as non-breaking
No description provided.
Comments (9)
-
Account Deactivated -
Account Deactivated - changed status to on hold
waiting for reporter's feedback
-
reporter The schema is being used in the response. And I was getting these results:
Then you mentioned about additionalProperties and I found out I had it set to false.
So I set the value to true and now I am getting this response
So, should addiontalProperties set to true if I am adding properties in the response object schema?
However, I was adding but the code says remove. Any insights to that?
-
reporter I also tried using the schema in a request, I am adding a new property in the request schema but the code says remove
-
reporter - changed status to open
added my comments
-
reporter - changed status to new
-
reporter any news on this please?
-
Account Deactivated The output is correct @Rico M .. When you have
additionalProperties: true
and you “add” a new property, you are not actually adding, but constraining that property from being anything to a specific value. For example, this schema{ type: object, additionalProperties: true, properties: { one: {type: string} } }
allows values like:
{}
,{one: "foo"}
,{one: "foo", two: 2}
,{one: "foo", two: "bar"}
,{two: []}
Notice it does support any property with any type (only constraint is that is property “one” is present must be string. However if you “add” a property
two
:{ type: object, additionalProperties: true, properties: { one: {type: string}, two: {type: number} } }
you are not actually adding,
two
was already supported by the first schema, you are constraining the possible values to be only numbers. So, from the previous examples the following values are no longer supported:{one: "foo", two: "bar"}
,{two: []}
. That’s why the type of the change is remove, you are constraining the scope of possible values by being more specific about the shape of the response. -
Account Deactivated - changed status to invalid
working as expected
- Log in to comment
Hi @Rico M , it might be breaking or not depending on other factors that I can’t see in the attached image:
additionalProperties
set to anything in particular (it defaults to true).I believe the case is this is a response schema and
additionalProperties
is not defined or set to true. Which means that consumers were before OK to receive values with any additional properties likefoo
or thenewRequiredPropertyAdded
of any type, and present or not. You just have made the domain of returned values more constraint but within the boundaries of what consumers already accepted.To simplify: if supported values (for a response) used to be
[1, 2, 3, 4, 5, 6]
and now are[3, 4]
.. nothing breaks, consumers already were accepting 3 and 4. However if you make the same change for a request schema, that would be breaking, consumers sticking to the old schema might be sending values like1
, or6
which the provider no longer accepts.