fish
Guppy
Posts: 65
|
Post by fish on Dec 1, 2017 13:08:57 GMT
Hi,
I think I have concluded the following from changes to Role schema. (OK?)
In 2017.2 schemas the RoleId property was added to Role resource.
This proerty is also annotated with requiredOnCreate, meaning that client will have to provide value at create (POST till role collection).
To me this looks like a none backward compatible change, beacuse clients that are not updated to the new schema yet will not provide the new property RoleId,
and updated servers will reject POST/create without this property. In short: this will break in case of old client towards new server. Also I think that annotation "requiredOnCreate" is fairly new, so older clients (or not so advanced clients) would not understand this anyway.
Do you agree that this is actually not backward compatible? Or am I misunderstanding something here?
Or how can I avoid backward compatibility issues here? (Scenario is to lift server implementation from older schemas to newest schemas.)
|
|
|
|
Post by jautor on Dec 7, 2017 17:52:09 GMT
In 2017.2 schemas the RoleId property was added to Role resource.
This proerty is also annotated with requiredOnCreate, meaning that client will have to provide value at create (POST till role collection).
To me this looks like a none backward compatible change, beacuse clients that are not updated to the new schema yet will not provide the new property RoleId, and updated servers will reject POST/create without this property. In short: this will break in case of old client towards new server. Also I think that annotation "requiredOnCreate" is fairly new, so older clients (or not so advanced clients) would not understand this anyway.
Do you agree that this is actually not backward compatible? Or am I misunderstanding something here?
Or how can I avoid backward compatibility issues here? (Scenario is to lift server implementation from older schemas to newest schemas.)
It is technically backward compatible because both the client and the service can use the schema version to indicate their support. But yes, this is a case where some care will need to be taken in implementation, and while it's not perfect, we are trying to minimize disruption to clients and services as much as possible - which means making fixes to ensure interoperability as we find them. That was the case here, as RoleId needs to be provided to create an account - as any "default" behavior may have negative implications. To allow this to work, a client should only POST to create an account using the schema version that the service supports, but normally, the Service should just ignore and discard unknown properties. Service can return a message showing what was discarded, and may choose to fail the request, too. Jeff |
|
fish
Guppy
Posts: 65
|
Post by fish on Dec 8, 2017 8:43:52 GMT
OK, thanks for the reply.
If similar situation would occur in the future I think it could maybe be a good idea to highlight this by stepping the major version of the schema to v2?
|
|
