Open APIs

 View Only
  • 1.  Meaning and implementation of href

    Posted Aug 11, 2022 08:17
     Hi,

    We are a Team that is new to the 'TMF-style Systems' domain and we have taken over a basic Service Ordering Management & Service Inventory Management and are currently setting up a Service Catalogue Management. As there is just limited functionality available, we want to restrict these systems to just a subset of the massive TMF APIs. We are also looking into streamlining the actual service implementation underneath the APIs and stumbled upon the href parameter.

    1. What is the expectation of the hrefs in the Service/Product domain?
      An href gives direct access to the element it belongs to, that much is clear.
      • However, does the link have to point to the "correct" destination even when it is several months old? Or is it ok if the href points nowhere some time after creation (for example: days). AFAIK, the href contains the TMF API version, and an API update could "break" this link.
    2. Is there any experience with the persistence of the href? We are setting up our first domain model and we want to reduce its complexity as much as possible. Generally, the hrefs contain redundant information so we had the idea of not storing them, but generating them on demand from the element's id and configurable parameters. Is this a reasonable way to go or are we missing some red flags?
    Thanks in advance for feedback.


    ------------------------------
    Simon Merz
    Deutsche Telekom AG
    ------------------------------


  • 2.  RE: Meaning and implementation of href

    TM Forum Member
    Posted Aug 11, 2022 09:58
    Hi Simon
    Firstly, welcome to the TMF Open API family.
    Please be aware that the Open API specs are just that, specifications. The implementation is up to you.
    hrefs are basically "smart" foreign keys. So no change from previous API exposure of foreign key. You have to decide if you will (for example) update foreign key in persistence when the referred entity is deleted, or rather be forgiving and expect your consumers to be resilient if they try to retrieve data from an orphaned foreign key.
    The only extra piece of information from the referred entity is the name, we have that because many display use cases want to show a title of a referred entity. Here also it's up to you how to represent this in persistence.
    Hope this helps

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