'5G Core APIs and Backward Incompatible Changes
In 3GPP TS 29501, section 6.3, there's information about backwards compatible/incompatible API changes for 5G Core APIs.
What I'm not able to figure out if there's a clear cut rule for request/response payloads? Should a payload always be valid given the NFs version of the API schema for changes to be backwards compatible?
E.g. let's say there's an integer attribute "foo" restricted to values between 0 and 10 in version 1.0.0. If the interval is changed to values between 0 and 20 in a later version, is that considered backwards compatible or not?
If it is considered backwards compatible since 0-10 is covered by 0-20 it means that a consumer should accept values not valid based on it's own API version? (e.g. receiving foo=17).
Solution 1:[1]
In the latest version TS 29.501 V17.5.0 Annex B (Informative) Backward Incompatible Changes. It states "Backward incompatible changes are additions or changes in the API that break the existing Service Consumer behaviour. "
In your example, if the consumer (e.g. UE) uses the new version with "0-20" while the producer (Network Provider) only supports the older version 1.0.0 "0-10", then I think it's not backward compatible bc the producer is unable to support a value larger than 10. The opposite would be OK, if the older version 1.0.0 was initially "0-20" and then the new version "0-10", it would be covered and considered backward compatible.
Best regards
Sources
This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.
Source: Stack Overflow
| Solution | Source |
|---|---|
| Solution 1 | JPSpacy |