Hi Thomas
It more widespread than just missing versions. At any place where an entity has a ref to another entity, that reference may not be able to be satisfied, for any number of reasons:
- Referred entity was deleted from its master storage
- Software component responsible for referred entity is down (presumably temporarily)
- Security principal in current context does not have read permissions on the referred entity
- ...
So it is the responsibility of the software that is managing the referring entity (Product in your example) to write code resiliently to manage the situation when the reference is unresolvable.
This would seem to me to fall into the area of sound software architecture and design, not specific to TMF Open APIs. So not sure if it is relevant to document e.g. in our design guidelines. But others might feel differently.
------------------------------
Jonathan Goldberg
Amdocs Management Limited
Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.
------------------------------
Original Message:
Sent: May 12, 2021 04:26
From: Thomas Dupré
Subject: How to deal with (possibly outdated) references that contain a version?
Hi,
not sure whether this topic was already raised, can't find it at the moment:
If an API references other resources and these references are persisted it may happen that the persisted referenced version is no longer valid in the target API.
Example (just one among many) where this general problem occurs: A product in the product inventory refers to realizingService:
"realizingService": [
{
"id": "12345",
"name": "MyService",
"href": ".../service-inventory/<Version>/service/12345"
}
]
- but the referenced service inventory API has meanwhile (e.g. over years) had some version upgrades -> the referenced version is now outdated -> any attempt to resolve the href will fail
The question is how to deal with such scenarios when the reference might become outdated over the time because of version updates:
- keep all versions alive, never deprecate one (practically not viable)
- rely not on href, only on id and resolve the reference "automatically" according to the most actual version (dangerous!)
- data migration in all referencing resources as soon as a version becomes outdated (practically not viable, would lead to strong coupling)
- ...?
Kind regards
Thomas
------------------------------
Thomas Dupré
Deutsche Telekom AG
------------------------------