0

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).

user3681243
  • 21
  • 3

1 Answers1

0

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

JPSpacy
  • 26
  • 2